On Aug 5, 2009, at 08:50, Pawel Jakub Dawidek wrote: > On Fri, Jul 31, 2009 at 11:05:01AM +0200, Thomas Backman wrote: >> I'm able to reliably reproduce this panic, by having zfs recv destroy >> a filesystem on the receiving end. >> >> 1) Use DDEBUG=1, I guess >> 2) Create a FS on the source pool you don't care about: zfs create -o >> mountpoint=/testfs source/testfs >> 3) Clone a pool to another: zfs snapshot -r source_at_snap && zfs send >> -R >> source_at_snap | zfs recv -Fvd target >> 4) zfs destroy -r source/testfs >> 4) zfs snapshot -r source_at_snap2 && zfs send -R -I snap source_at_snap2 | >> zfs recv -Fvd target >> 5) ^ Panic while receiving the FS the destroyed one is mounted under. >> In my case, this was tank/root three times out of three; I then tried >> creating testfs under /tmp (tank/tmp/testfs), *mounting* it under / >> usr/ >> testfs, and it panics on receiving tank/usr: > [...] > > I repeated precisevly those steps and it doesn't panic for me. > Could you confirm that you use this patch? > > http://people.freebsd.org/~pjd/patches/zfs_vnops.c.2.patch > > If so, could you give me exact steps and all of them how to > reproduce it? > Starting with pool creation. Yup, I'm using that patch (I diffed the diffs, heh). I'll try to write a script to recreate the panic; I hope it's as easy as in real-world conditions though. Regards, ThomasReceived on Wed Aug 05 2009 - 05:09:34 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:53 UTC