dd if=/dev/zero of=sl1 bs=512 count=256000 dd if=/dev/zero of=sl2 bs=512 count=256000 dd if=/dev/zero of=sl3 bs=512 count=256000 dd if=/dev/zero of=sl4 bs=512 count=256000 zpool create -m /export/test1 test1 raidz /export/sl1 /export/sl2 /export/sl3 zpool add -f test1 /export/sl4 dd if=/dev/zero of=sl4 bs=512 count=256000 zpool scrub test1 panic. and message like on image. This message posted from opensolaris.org -------------- next part -------------- A non-text attachment was scrubbed... Name: aa.png Type: image/png Size: 8487 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20070609/f6d4c95a/attachment.png>
You have created an unreplicated pool of the form: pool raidz /export/sl1 /export/sl2 /export/sl3 /export/sl4 I believe ''zpool add'' will warn you about this, hence needing the ''-f''. You then overwrite the entire contents of /export/sl4, causing ZFS to reopen the device, only to not recognize the device and therefore mark it FAULTED. Because you are in an unreplicated pool, you then tripped over: 6413847 vdev label write failure should be handled more gracefully Which is just one manifestation of a series of issues currently being worked on where a failed writes in an unreplicated config can cause ZFS to panic. Using a replicated config will prevent this problem from happining in the future. - Eric On Sat, Jun 09, 2007 at 11:50:43AM -0700, Fyodor Ustinov wrote:> dd if=/dev/zero of=sl1 bs=512 count=256000 > dd if=/dev/zero of=sl2 bs=512 count=256000 > dd if=/dev/zero of=sl3 bs=512 count=256000 > dd if=/dev/zero of=sl4 bs=512 count=256000 > zpool create -m /export/test1 test1 raidz /export/sl1 /export/sl2 /export/sl3 > zpool add -f test1 /export/sl4 > dd if=/dev/zero of=sl4 bs=512 count=256000 > zpool scrub test1 > > panic. and message like on image. > > > This message posted from opensolaris.org-- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock
For the record, I was able to get this same panic when I dd''d /dev/zero over a file that was part of my own test pool. Specifically, I had files of sizes 128M 192M 192M 256M in a simple pool with copies=2. I put a 109M file on the filesystem and ran ''dd count=1 bs=192M if=/dev/zero of=disk2''. Then I ran ''zpool scrub virt'' and that caused me to lose contact to the box (which was miles away, unfortunately). I found the box with a corrupt /etc/svc/repository.db, which I restored according to svc''s instructions. After that, Solaris entered a reboot cycle with the spa.c:2910 panic on every bootup. I was able to escape that with safe mode, but even ''zpool destroy virt'' would cause the panic. Finally I put back the 192M file (a copy I made just before zeroing the contents) and then I was able to destroy the pool. SunOS Release 51 Version NexentaOS_20070402 32-bit This message posted from opensolaris.org