Panic on snv_65&64 when: #mkdir /disk #mkfile 128m /disk/disk1 #mkfile 128m /disk/disk2 #zpool create data mirror /disk/disk1 /disk/disk2 #mkfile 128m /disk/disk1 #mkfile 128m /disk/disk2 #zpool scrub data panic[cpu0]/thread=2a100e33ca0: ZFS: I/O failure (write on <unknown> off 0: zio 30002925770 [L0 bplist] 4000L/4000P DVA[0]=<0:10000:4000> DVA[1]=<0:1810000:4000> DVA[2]=<0:3010000:4000> fletcher4 uncompressed BE contiguous birth=15 fill=1 cksum=1000000:1000000000:800800000000:2ab2ab000000000): error 6 000002a100e33900 zfs:zio_done+2a0 (30002925770, 30002925770, 6, 7b656730, 30003f5e2c0, 30001801580) %l0-3: 0000030002b74fe8 0000000000000002 000000000000000f 0000000000000006 %l4-7: 0000000000000006 0000000000000003 0000000000000010 0000000000000000 000002a100e339c0 genunix:taskq_thread+19c (30002878a30, 30002878a88, 50001, ae06717577, 2a100e33a8a, 2a100e33a88) %l0-3: 0000000000010000 0000030002878a62 0000030002878a60 0000030002878a58 %l4-7: 0000030003f704a0 0000000000000002 0000000000000000 0000030002878a50 syncing file systems... done dumping to /dev/dsk/c0t0d0s1, offset 215154688, content: kernel 100% done: 15297 pages dumped, compression ratio 3.28, dump succeeded rebooting.. My system is: #uname -a SunOS blade150 5.11 snv_65 sun4u sparc SUNW,Sun-Blade-100 This message posted from opensolaris.org
I think this falls under the bug (of which the number I do not have handy at the moment) where ZFS needs to more gracefully fail in a situation like this. Yes, be probably broke his zpool, but it really shouldn''t have paniced the machine. -brian On Mon, Jun 11, 2007 at 03:05:19PM -0100, Mario Goebbels wrote:> I think in your test, you have to force some IO on the pool for ZFS to > recognize that your simulated disk has gone faulty, and that after the > first mkfile already. Immediately overwriting both files after pool > creation leaves ZFS with the impression that the disks went missing. And > even if ZFS noticed by itself, you still need to allow it to perform and > complete a resilver after issuing the first mkfile. > > -mg > > > Panic on snv_65&64 when: > > #mkdir /disk > > #mkfile 128m /disk/disk1 > > #mkfile 128m /disk/disk2 > > #zpool create data mirror /disk/disk1 /disk/disk2 > > #mkfile 128m /disk/disk1 > > #mkfile 128m /disk/disk2 > > #zpool scrub data > > > > panic[cpu0]/thread=2a100e33ca0: ZFS: I/O failure (write on <unknown> off 0: zio 30002925770 [L0 bplist] 4000L/4000P DVA[0]=<0:10000:4000> DVA[1]=<0:1810000:4000> DVA[2]=<0:3010000:4000> fletcher4 uncompressed BE contiguous birth=15 fill=1 cksum=1000000:1000000000:800800000000:2ab2ab000000000): error 6 >> _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss-- "Perl can be fast and elegant as much as J2EE can be fast and elegant. In the hands of a skilled artisan, it can and does happen; it''s just that most of the shit out there is built by people who''d be better suited to making sure that my burger is cooked thoroughly." -- Jonathan Patschke
I think in your test, you have to force some IO on the pool for ZFS to recognize that your simulated disk has gone faulty, and that after the first mkfile already. Immediately overwriting both files after pool creation leaves ZFS with the impression that the disks went missing. And even if ZFS noticed by itself, you still need to allow it to perform and complete a resilver after issuing the first mkfile. -mg> Panic on snv_65&64 when: > #mkdir /disk > #mkfile 128m /disk/disk1 > #mkfile 128m /disk/disk2 > #zpool create data mirror /disk/disk1 /disk/disk2 > #mkfile 128m /disk/disk1 > #mkfile 128m /disk/disk2 > #zpool scrub data > > panic[cpu0]/thread=2a100e33ca0: ZFS: I/O failure (write on <unknown> off 0: zio 30002925770 [L0 bplist] 4000L/4000P DVA[0]=<0:10000:4000> DVA[1]=<0:1810000:4000> DVA[2]=<0:3010000:4000> fletcher4 uncompressed BE contiguous birth=15 fill=1 cksum=1000000:1000000000:800800000000:2ab2ab000000000): error 6-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 648 bytes Desc: This is a digitally signed message part URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20070611/57bad0a4/attachment.bin>
On Jun 11, 2007, at 12:52 AM, Borislav Aleksandrov wrote:> Panic on snv_65&64 when: > #mkdir /disk > #mkfile 128m /disk/disk1 > #mkfile 128m /disk/disk2 > #zpool create data mirror /disk/disk1 /disk/disk2 > #mkfile 128m /disk/disk1 > #mkfile 128m /disk/disk2At this point you have completely overwritten the entire contents of both sides of the mirror. No filesystem can recover from that. If you just overwrite one side of the mirror, then you''ll be ok. eric