gvinum striped corruption?

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