vinum error: statfs related?
Daryl Chance
chancedj at yahoo.com
Wed Nov 19 06:26:00 PST 2003
Any more word on this?
I haven't tried creating a new volume to see if it
will create because i don't want to loose wants
currently there.
Not trying to harrass anyone, just checking :).
Daryl
--- Robert Watson <rwatson at FreeBSD.ORG> wrote:
>
> On Fri, 17 Jan 2003, Eric Anholt wrote:
>
> > I'm getting the same (no
> drives/subdisks/plexes/volumes found) trying to
> > upgrade from a Nov 11 kernel/userland to Nov 16th
> kernel. I tried
> > seeing if using a Nov 16th vinum binary would load
> them, but after doing
> > a stop/start, the system paniced, and it seems my
> swap is too small to
> > dump on. Kernel was built using configure
> MYKERNEL; cd
> > ../compile/MYKERNEL; make depend all install
> instead of buildkernel. DDB
> > enabled but no invariants/witness, not sure what
> else from my config
> > might be applicable.
>
> I'm able to trigger this warning simply by starting
> and stopping Vinum
> without a Vinum configuration:
>
> ttyp0:
> crash2# vinum start
> ** no drives found: No such file or directory
> crash2# vinum stop
> vinum unloaded
>
> console:
> vinum: loaded
> vinum: no drives found
> vinum: exiting with malloc table inconsistency at
> 0xc2053c00 from
> vinumio.c:755
> vinum: unloaded
>
> I attempted to experiment some with Vinum today.
> After fixing a bug in
> the vinum user tool to stop trying to create device
> nodes and directories
> in devfs, it seemed to come up OK (fix committed).
> I documented the bug
> that vinum won't work with storage devices with
> sector sizes other than
> DEV_BSIZE (512) in the vinum.8 man page, since I
> don't have time to fix it
> today. I created a malloc md-backed vinum array
> with seeming ease, but
> was unable to newfs the result:
>
> ttyp0:
> crash2# mdconfig -a -t malloc -s 1m
> md0
> crash2# mdconfig -a -t malloc -s 1m
> md1
> crash2# mdconfig -a -t malloc -s 1m
> md2
> crash2# vinum
> vinum -> concat /dev/md0 /dev/md1 /dev/md2
> vinum -> quit
> crash2# newfs /dev/vinum/vinum0
> /dev/vinum/vinum0: 2.6MB (5348 sectors) block size
> 16384, fragment size 2048
> using 4 cylinder groups of 0.66MB, 42
> blks, 128 inodes.
> super-block backups (for fsck -b #) at:
> 160, 1504, 2848, 4192
> cg 0: bad magic number
>
> console:
> vinum: loaded
> vinum: drive vinumdrive0 is up
> vinum: drive vinumdrive1 is up
> vinum: drive vinumdrive2 is up
> vinum: vinum0.p0.s0 is up
> vinum: vinum0.p0.s1 is up
> vinum: vinum0.p0.s2 is up
> vinum: vinum0.p0 is up
> vinum: vinum0 is up
>
> So clearly UFS is unhappy with something about the
> array. I tried
> reading/writing stuff to/from the array with pretty
> mixed results:
>
> ttyp0:
> crash2# diskinfo /dev/vinum/vinum0
> /dev/vinum/vinum0 512 2738688 5349
> crash2# dd if=/dev/random of=/data.file bs=512
> count=5349
> 5349+0 records in
> 5349+0 records out
> 2738688 bytes transferred in 2.520634 secs
> (1086508 bytes/sec)
> crash2# dd if=/data.file of=/dev/vinum/vinum0
> bs=512 count=5349
> 5349+0 records in
> 5349+0 records out
> 2738688 bytes transferred in 2.464483 secs
> (1111263 bytes/sec)
> crash2# dd if=/dev/vinum/vinum0 of=/data.file2
> bs=512 count=5349
> 5349+0 records in
> 5349+0 records out
> 2738688 bytes transferred in 2.467386 secs
> (1109955 bytes/sec)
> crash2# ls -l /data.f*
> -rw-r--r-- 1 root wheel 2738688 Nov 17 17:02
> /data.file
> -rw-r--r-- 1 root wheel 2738688 Nov 17 17:03
> /data.file2
> crash2# md5 /data.file*
> MD5 (/data.file) =
> ce76d17b337f70c1d4d53b48cf08f906
> MD5 (/data.file2) =
> b1d08e0fe52ecff364a894edf43caef2
>
> The reason for the somewhat long copy times is that
> / for this box is out
> of NFS. To be sure, I ran this a second time:
>
> MD5 (/data.file.3) =
> d0c9d71cfacedc70358be028f0c346dd
> MD5 (/data.file.4) =
> 0ea319da8e68550c2ebf91e6b1618976
>
> It sounds like there's a serious problem with Vinum
> right now. I took a
> look through the vinum data structures, and I
> couldn't see any obvious
> problems that could have stemmed from the statfs()
> change: specifically, I
> didn't see any data structures that would have
> changed size as a result of
> the change. So I'm guessing it was some other
> similarly timed change, but
> I'm not sure what.
>
> It's interesting to observe that I didn't get the
> malloc failure when I
> unloaded Vinum after the above tests: it appears to
> occur as a result of a
> configuration difficulty (such as a failure to find
> one), and so may
> actually be a red herring for the underlying
> problem. Or at least, an
> independent bug/feature.
>
> I'm heading home for the day, when I head home, I'll
> try changing around
> the testing procedure to attempt to identify what
> exactly is getting
> corrupted in my dd tests.
>
> Robert N M Watson FreeBSD Core Team,
> TrustedBSD Projects
> robert at fledge.watson.org Network Associates
> Laboratories
>
__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree
More information about the freebsd-current
mailing list