gvinum striped corruption?
Stijn Hoop
stijn at win.tue.nl
Wed Oct 13 03:37:38 PDT 2004
On Wed, Oct 13, 2004 at 12:24:09PM +0200, Lukas Ertl wrote:
> On Wed, 13 Oct 2004, Stijn Hoop wrote:
> > On Wed, Oct 13, 2004 at 08:01:52AM +0100, Ryan Hunt wrote:
> > > I'm trying to get vinum (geom) happening in BETA7, but I'm finding
> > >that 'resetconfig' it not available yet (among other commands)..
> >
> > As a workaround, you maybe you can obliterate the previous configuration
> > by dd'ing /dev/zero to the first 257 sectors of the relevant vinum
> > 'drives'. I'd do this without geom_vinum loaded though.
>
> Or you could just 'gvinum rm -r <drive>'.
Well d'oh. Of course. Why didn't I think of that :)
> > No idea as to your other answers; I'm still not sure whether I'm
> > experiencing data corruption on a concat volume due to geom_vinum but I
> > don't have the time to debug this.
>
> I don't recall if you sent me some info about this (of course. I'm
> drowning in email, so maybe I just overlooked it :-) ).
No I didn't, precisely because I'm not sure whether it is geom_vinum that is
the culprit. All I know for now is that a -CURRENT kernel with regular vinum
from way back in May works, and a -CURRENT kernel with geom_vinum from around
the 21st september (including the commit from sept. 18, geom_vinum.h r1.6 etc)
doesn't. It might be a bug in ATA, or something else, I dunno.
I discovered the issue because BitTorrent complained about on-disk corruption.
Sure enough, data downloaded kept having different MD5's and archives didn't
extract properly. Even stranger, checksum verification fails differently on
every run:
[stijn at pcwin002] </local/storage> cksfv -f somefile.sfv
--( Verifying: somefile.sfv )---------------------------------------------------
somefile.001 OK
somefile.002 OK
somefile.003 different CRC
....
[stijn at pcwin002] </local/storage> cksfv -f somefile.sfv
--( Verifying: somefile.sfv )---------------------------------------------------
somefile.001 different CRC
somefile.002 different CRC
somefile.003 different CRC
....
Data written with the older setup appears to be intact when I boot the older
kernel, but then my userland is whacked (of course). I haven't had the time
to dig any deeper than that (e.g. does data written by geom_vinum work when
read by older vinum).
gvinum lv -vr output:
gvinum -> lv -vr
1 volume:
Volume stor: Size: 120118026240 bytes (114553 MB)
State: up
Plex stor.p0: Size: 120118026240 bytes (114553 MB)
Subdisks: 2
State: up
Organization: striped Stripe size: 279 kB
Part of volume stor
Subdisk stor.p0.s0:
Size: 60059013120 bytes (57276 MB)
State: up
Plex stor.p0 at offset 0 (0 B)
Drive stor0 (stor0) at offset 135680 (132 kB)
Subdisk stor.p0.s1:
Size: 60059013120 bytes (57276 MB)
State: up
Plex stor.p0 at offset 285696 (279 kB)
Drive stor1 (stor1) at offset 135680 (132 kB)
Hmm it's striped, not concat: sorry for the confusion!
This is all the info I can provide right now (not at the console of the box
atm). If I can squeeze it in I'll try and test some more tomorrow. Do you have
suggestions on what to test?
--Stijn
--
A "No" uttered from deepest conviction is better and greater than a
"Yes" merely uttered to please, or what is worse, to avoid trouble.
-- Mahatma Ghandi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20041013/673037dc/attachment.bin
More information about the freebsd-current
mailing list