On Jul 31, 2009, at 13:45, James R. Van Artsdalen wrote: > Andriy Gapon wrote: >> on 30/07/2009 17:39 Thomas Backman said the following: >> >>> Or, in patch form (I think the intendation screws the patch up as >>> linked >>> there): >>> http://exscape.org/temp/libzfs_sendrecv.patch >>> >> >> One comment on the patch - I personally don't like bit-wise xor in >> a logical >> expression. But if otherwise the expression would be huge and ugly, >> then OK. >> > > If you're going to code an XOR, use an XOR. > Don' make the reader untangle code to figure out that that some other > code is really just an XOR. > > However I think I was trying to handle two cases that can't happen: > the > top filesystem cannot be renamed to somewhere else in the pool, and no > other filesystem can be renamed to the root. So the new version of > the > patch below needs no XOR. > > Without this or something like it you can't replicate an entire > pool, i.e. > > zfs send -R -I _at_yesterday pool_at_today | ssh backup zfs recv -vF -d > pool > > dumps core from the strccmp(0, 0) in the original code below. > > > Index: cddl/contrib/opensolaris/lib/libzfs/common/libzfs_sendrecv.c > =================================================================== > ... Nice job, thanks :) Just wanted to chime in and say that your new patch seems to work just as well as the previous one. I hope you don't mind me hosting this too (I had to apply it manually thanks to spacing... I think it's my mail client not being very nice at retaining tabs/spaces)... Straight from svn diff: http://exscape.org/temp/libzfs_sendrecv.new.patch BTW (maybe not on topic for this mail, but for this thread), I've created a test case to reproduce the new panic (every time). It happens with -DDEBUG=1, after destroying a filesystem and then doing an incremental backup. Currently recompiling world/kernel on a second box to reproduce before I post that. Regards, ThomasReceived on Fri Jul 31 2009 - 10:27:51 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:53 UTC