From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from ar.aichi-u.ac.jp ([202.250.160.40]) by ttr; Mon May 5 08:08:55 EDT 2014 Received: from [192.168.1.105] ([125.193.25.135]) by ar; Mon May 5 21:08:47 JST 2014 Content-Type: text/plain; charset=iso-2022-jp Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: [9front] cwfs fsmempercent From: arisawa In-Reply-To: Date: Mon, 5 May 2014 21:08:44 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <8EF39ECC-AB9C-4C8B-94CA-B3CAEB5F7471@ar.aichi-u.ac.jp> List-ID: <9front.9front.org> X-Glyph: ➈ X-Bullshit: database XML injection content-driven plugin callback locator References: <79CB058C-F091-4CEB-9F0B-D01864EE5973@ar.aichi-u.ac.jp> To: 9front@9front.org X-Mailer: Apple Mail (2.1510) Hello cinap, by the way, I am feeling uneasy. you don't memset(). assuming that other processes can know only physical memory and used = memory of the system, that is, if they don't know reserved memory (allocated memory), then they might misunderstand memory size they can allocate. isn't this make a problem? On 2014/05/05, at 20:15, arisawa wrote: > now I could succeed to update by hg. >=20 > I don't know why I was in trouble. > probably straggling led me to bad way. > send time, I reinstalled /dist/plan9front/ and get success. > your fix is nice! >=20 > thanks a lot. >=20 > by the way, a command name 9hg may be useful. >=20 > #!/bin/rc > rfork n > cd / > if(! test -d .hg) > bind -ac /dist/plan9front / > if(! ~ $#* 0) > hg $* > if not > hg help | awk '/^ [a-z]*/ {s=3D$0; sub(" *[a-z]* *","",s); = printf("9hg %s\t# %s\n", $1, s)}' >=20 >=20 >=20 >=20 >=20 > On 2014/05/05, at 17:00, arisawa wrote: >=20 >> I have cleaned directories below: >> /dist/plan9front/ >> /sys/lib/python/mercurial/ >> /sys/lib/python/hgext/ >> /sys/src/cmd/hg/ >> and reinstalled them using latest iso image from 9front = (=1B$B'`'a'V'_=1B(B-=1B$B'c'c'c']=1B(B). >> and then >> (1) allowed mode to cwfs64x >> (2) auth/as glenda sysupdate >>=20 >> note that host owner of my terminal is "arisawa". >>=20 >> term% pwd >> /dist/plan9front >> term% ls -l >> d-rwxrwxr-x M 20 glenda sys 0 Apr 28 06:31 .hg >> --rw-rw-r-- M 20 glenda sys 724 Jun 15 2013 .hgignore >> term% ls -ld .hg/store >> d-rwxrwxr-x M 20 glenda sys 0 May 5 15:47 .hg/store >> term% ls -l .hg/store >> --rw-rw-r-- M 20 glenda sys 745978 May 4 22:05 = .hg/store/00changelog.d >> --rw-rw-r-- M 20 glenda sys 228608 Apr 28 06:20 = .hg/store/00changelog.i >> --rw-rw-r-- M 20 glenda sys 1521917 May 4 22:05 = .hg/store/00manifest.d >> --rw-rw-r-- M 20 glenda sys 165888 May 4 22:05 = .hg/store/00manifest.i >> d-rwxrwxr-x M 20 glenda sys 0 Apr 12 2013 .hg/store/data >> --rw-rw-r-- M 20 glenda sys 967509 May 4 22:05 .hg/store/fncache >> --rw-rw-r-- M 20 glenda sys 222 Apr 28 06:20 .hg/store/undo >> term%=20 >>=20 >> what else should I examine? >>=20 >> it seems "*.d" and "*.i" files are compressed. >> I am happier if I can decompress these file, because I have your = update in "*.i" format. >>=20 >> term% ls -tl .hg/store/data/sys/src/cmd/cwfs |head >> --rw-rw-r-- M 20 glenda sys 2777 May 4 22:05 = .hg/store/data/sys/src/cmd/cwfs/iobuf.c.i >> --rw-rw-r-- M 20 glenda sys 1686 May 4 20:15 = .hg/store/data/sys/src/cmd/cwfs/all.h.i >> --rw-rw-r-- M 20 glenda sys 2777 Feb 14 23:09 = .hg/store/data/sys/src/cmd/cwfs/malloc.c.i >> --rw-rw-r-- M 20 glenda sys 7113 Feb 4 04:05 = .hg/store/data/sys/src/cmd/cwfs/portdat.h.i >> --rw-rw-r-- M 20 glenda sys 5523 Oct 17 2013 = .hg/store/data/sys/src/cmd/cwfs/chk.c.i >> --rw-rw-r-- M 20 glenda sys 16946 Oct 16 2013 = .hg/store/data/sys/src/cmd/cwfs/cw.c.i >> --rw-rw-r-- M 20 glenda sys 9457 Aug 8 2013 = .hg/store/data/sys/src/cmd/cwfs/sub.c.i >> --rw-rw-r-- M 20 glenda sys 5470 Aug 8 2013 = .hg/store/data/sys/src/cmd/cwfs/net.c.i >> --rw-rw-r-- M 20 glenda sys 3357 Aug 8 2013 = .hg/store/data/sys/src/cmd/cwfs/srv.c.i >> --rw-rw-r-- M 20 glenda sys 7795 Aug 8 2013 = .hg/store/data/sys/src/cmd/cwfs/main.c.i >> term%=20 >>=20 >> On 2014/05/05, at 13:32, cinap_lenrek@felloff.net wrote: >>=20 >>> this is an exception happening in >>>=20 >>> /sys/src/cmd/hg/mercurial/mpatch.c:424 >>>=20 >>> parsing a revlog file. each file tracked by mercurial has >>> a revlog file containing the changes of this file. (binary >>> patches). these files are append only. >>>=20 >>> unfortunately, that stacktrace doesnt tell us what file >>> is corrupted. >>>=20 >>> what exactly did you do? >>>=20 >>> -- >>> cinap >>=20 >=20