Re: vinum error: statfs related?
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 [EMAIL PROTECTED] 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 (263 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 [EMAIL PROTECTED] Network Associates Laboratories __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree ___ [EMAIL
Re: vinum error: statfs related?
At Sun, 16 Nov 2003 20:14:24 -0800 (PST), Daryl Chance wrote: I am currently not able to load my vinum array (haven't tried to revert back to pre-statfs source) Me too. After upgrading the kernel from -current as of mid september to today's, I rebooted and got vinum loaded, no drives found message. Rebooting with old kernel (and modules) brings back the vinum objects back again. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vinum error: statfs related?
On Sun, 2003-11-16 at 20:14, Daryl Chance wrote: I am currently not able to load my vinum array (haven't tried to revert back to pre-statfs source) after I built a new kernel and world. I upgraded the recommended way (installkernel, reboot, single user mode, installworld, etc) and when my box boots I get vinum loaded, no drives found. When I go to kldunload vinum, it unloads but I get the error: vinum: exiting with malloc table inconsistency at 0xc2f49400 from vinumio.c:755 vinum: unloaded I checked the pr's, but haven't seen anything yet listed in there. Should I do a sendpr? I'm basically using the generic conf, with the exception that I've removed 486 and 586 and changed the ident. I don't have a lint config, so i don't know how to compile vinum into the kernel to test if that fixes it. If theres anymore info needed, I'd be glad to give access to the box or email a dmesg. 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. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vinum error: statfs related?
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 (263 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 [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
vinum error: statfs related?
I am currently not able to load my vinum array (haven't tried to revert back to pre-statfs source) after I built a new kernel and world. I upgraded the recommended way (installkernel, reboot, single user mode, installworld, etc) and when my box boots I get vinum loaded, no drives found. When I go to kldunload vinum, it unloads but I get the error: vinum: exiting with malloc table inconsistency at 0xc2f49400 from vinumio.c:755 vinum: unloaded I checked the pr's, but haven't seen anything yet listed in there. Should I do a sendpr? I'm basically using the generic conf, with the exception that I've removed 486 and 586 and changed the ident. I don't have a lint config, so i don't know how to compile vinum into the kernel to test if that fixes it. If theres anymore info needed, I'd be glad to give access to the box or email a dmesg. __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
