Closed GoogleCodeExporter closed 8 years ago
I'm on the road without access to the original logs, but after doing some
preliminary research on this, my hypothesis is that this is a kernel stack
overflow caused by recursion in the vnode_reclaim code. I haven't been able to
confirm what the reclaim is for, but I'm assuming it's a form of garbage
collection or cache cleaning in a filesystem's UBC. I'll check in with the list
on this.
Original comment by buffer.g...@gmail.com
on 16 Feb 2011 at 8:11
The ZFS reclaim (or more generally, reclaim in OSX vnode parlance) is the
cleanup of any FS-specific resources associated with the OSX vnode. It
typically happens after a file is deleted. Whereas in the upstream Solaris
code, which cleans up the resources upon delete, in OSX the clean is split into
two parts; cleaning up the ZFS data and then cleaning up the VNode.
I know I need to look into this some more because it's the same issue with the
MacZFS 77 code. I'm also not sure if we might be better off with ditching the
zfs_reclaim stuff and just having the code in the zfs_delete node.
You might find that whilst this doesn't happen under high load all the time
that it happens when many deletions are taking place. Creating or updating
files is less likely to trigger this panic.
Original comment by alex.ble...@gmail.com
on 16 Feb 2011 at 9:32
I'm finding that this doesn't seem to happen in connection with file deletions,
with the notable exception of crashes caused by htclean (the cache cleaning
process for Apache running as a proxy server). I can't be sure, since we don't
seem to get which system call was made by the application identified as the
source of the panic, but some of these applications don't appear to be doing
anything more than scanning directories or mount points for initialising an
installer (installd) or present a file selection dialogue.
Apple's suggestion to resolve these kinds of issues is to replace recursive
algorithms with iterative ones. I've only scanned the code thus far and have no
clear idea whether this is practical. I'd love to increase the stack size as a
workaround, but as far as I can work out, this is non-trivial, as the sysctl
kern.stack_size setting is read-only. There's not a lot of documentation on
this variable, but it appears to require kernel recompilation.
Original comment by buffer.g...@gmail.com
on 2 Mar 2011 at 8:46
Original comment by alex.ble...@gmail.com
on 19 Mar 2011 at 8:31
Original issue reported on code.google.com by
buffer.g...@gmail.com
on 6 Feb 2011 at 2:36