On Jul 30, 2009, at 16:24, Andriy Gapon wrote: > > Could you please add DEBUG_VFS_LOCKS to kernel config and check that > we haven't > broke VFS locking with the patch? > Thank you again! > > -- > Andriy Gapon Hey, thank *you* :) Currently recompiling the kernel, I'll have a look later. What do I do, though? Just keep an eye on the console, or something more involved? (Or, since the handbook mentions lockedvnods in ddb: when should I check lockedvnods?) BTW: Could you (or anyone else with knowledge in these areas) have a look at the libzfs_sendrecv patch? Final piece of the puzzle as far as all the panics (well, core dump in this case) I've ran in to is concerned. http://lists.freebsd.org/pipermail/freebsd-current/2009-May/006814.html Or, in patch form (I think the intendation screws the patch up as linked there): http://exscape.org/temp/libzfs_sendrecv.patch Appears to be a pretty simple patch. I've tried writing a test case, but it's a bit of work to make it create separate pools, etc, so I'd rather skip that if possible. Without the patch, I can't get send -R - I (recursive + auto-incremental, i.e. you can do -I snap1 tank_at_snap4 instead of -i snap1 -i snap2 ...) to work without core dumping on the recv (sending to a file works just fine, but when receiving from the file, it core dumps; of course, the same is true for a pipe). Regards, ThomasReceived on Thu Jul 30 2009 - 12:39:52 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:52 UTC