I've been seeing corruption of fossil /archive data, at a rate of about
once a week. The symptom is that venti dir entries for /archive copies
of some frequently referenced directories in my main fossil fs (generally
it's /usr, /usr/miller or /mail/box/miller) contain incorrect venti scores.
I'm having a continuous problem, symptom being failures in archWalk,
but had assumed it was a hard disk getting ready to die.
fossil: diskReadRaw failed: /dev/sdC0/fossil: score 0x0021cac2:
part=label block 2214594: illegal block address
archive(0, 0x4d385643): cannot find block: error reading
I'm having a continuous problem, symptom being failures in archWalk,
but had assumed it was a hard disk getting ready to die.
i see those on one of my old drives, but i don't think
it's the drive. i thought it might have been
caused by a power failure catching out fossil or venti,
but if you've
archive(0, 0x4d385643): cannot find block: error reading block 0x0021cac2
archWalk 0x4d385643 failed; ptr is in 0x2075 offset 3
0x4d385643 is supposedly a block number, which seems unlikely unless
you have a 10 terabyte disk. Looks like you have a VtEntry or pointer
block with a corrupted
ls: 0216/mail/box/cinap_lenrek/mbox: '0216/mail' does not exist
ls: 0323/mail/box/cinap_lenrek/mbox: '0323/mail/box' does not exist
oops... :(
Schade.
Is this a uni- or multi-processor?
cd /n/dump/2009
for (i in *) { test -d $i$home/tmp || ls -d $i$home/tmp }
for (i in *) { test -f $i/mail/box/$user/mbox || ls $i/mail/box/$user/mbox }
no problems here, and my server is a dual cpu PIII.
I last built a kernel on the 11th of feb so if this is a very recent but I may
have
uniprocessor machine
--
cinap
uniprocessor machine
That eliminates some lines of investigation, thank you.
could it be that the archiver for some reason is looking
at rolled back blocks?
I'll put in a console message when blocks are rolled back and
see if there's a correlation.
md5sum: error reading /n/sources/plan9/sys/src/boot/pc/ether82563.c: venti
i/o error or wrong score, block 72804bdc64d1a772cd4b2eaeda6f1e1b8f175b21
I have got similar problem with 'pull'.
And the last update even ruined binaries of NDB... :-(
Pavel
never mind. i think it's not a sign of the problem we were discussing,
but possibly something is simply down.
Then the error message needs some tidying up. It happened to me too
and coincided with a total failure for replica. Sigh!
++L
On Mon Mar 30 15:10:25 EDT 2009, lu...@proxima.alt.za wrote:
never mind. i think it's not a sign of the problem we were discussing,
but possibly something is simply down.
Then the error message needs some tidying up. It happened to me too
and coincided with a total failure for replica.
i've seen that just recently, but thought it might have been
a failing (very old) drive, or a power failure beyond the endurance of the UPS.
if neither of those are true in your case, it might be worth a deeper look.
i also found there is a persistent problem that `check fix' won't fix.
(since
This is likely too large a hammer, but when this happens I rebuild the
venti index
so that I can get past the issue. I see this more under Plan 9 than p9p. The
block in error always exists in an arena and a checkarenas reports no errors.
The problem usually persists across reboots until I
On Sat Mar 28 06:54:35 EDT 2009, fors...@terzarima.net wrote:
i've seen that just recently, but thought it might have been
a failing (very old) drive, or a power failure beyond the endurance of the
UPS.
if neither of those are true in your case, it might be worth a deeper look.
i also found
On Sat, Mar 28, 2009 at 11:11:25AM +, Charles Forsyth wrote:
i've seen that just recently, but thought it might have been
a failing (very old) drive, or a power failure beyond the endurance of the
UPS.
if neither of those are true in your case, it might be worth a deeper look.
i also
AFAIK the disk is doing just fine. Moreover, even during the period when
fossil is complaining, venti/read on 9fs's score works just fine. So I
don't believe the fault is venti's.
i don't believe that conclusion is warranted.
/sys/src/cmd/fossil/cache.c:683,684
is where this condition gets
On Sat, Mar 28, 2009 at 01:31:01PM -0400, erik quanstrom wrote:
it would be interesting to know if the score
of the block returned by venti/read is correct.
venti/read should be doing this check automatically since libventi/client.c
builds with int ventidoublechecksha1 = 1; by default.
--nwf;
sorry if this is a dupe. my original reply seems to
have gone missing due to a local mishap.
venti/read should be doing this check automatically since libventi/client.c
builds with int ventidoublechecksha1 = 1; by default.
yet you're reporting that fossil thinks the score does not
match.
Entertaining. Indented lines are fossil console; nonindented are at a
normal CPU prompt.
cpu% 9fs
9fs: venti i/o error or wrong score, block
558b88fbae4e0aa894c614fb3eeccf4d2f7492ca
main: venti tcp!xxx.xxx.xxx.xxx!x
cpu% 9fs
9fs: venti i/o error or wrong score, block
19 matches
Mail list logo
