> When defining DONT_CACHE_MEMORY_OBJECTS in ext2fs.h, a thread can get stuck
> in memcpy(), pager/pager-memcpy (called by diskfs/rdwr-internal, called by
> io_read). I can provide a gdb trace if someone is interested.
What that means is that it is blocked on a page fault and the file pager is
not responding for some reason. (You can tell especially easily when
pager-memcpy is involved, since that function exists to do copies that
will fault to one of our own pagers.) Hopefully there is another thread in
the filesystem that is trying to handle the page fault and is blocked for
some reason, so you can look at that thread and figure something out.
> About the purpose of this symbol, I could only find the ChangeLog:
Well, it just toggles a flag in a call (RPC) to the kernel. The real
meaning of this lies in the external pager interface and Mach VM semantics.
> What effect would have (no) caching of memory objects on the zero hole bug
> situation?
I believe that what this controls is whether the kernel may decide to keep
a pager object alive when there are no more mappings to it from any task.
The pager object in libdiskfs keeps the node object alive, so this affects
when in-core node objects might get cleaned up and recreated. If this
caching is enabled, then e.g. in a small window where noone had a file
open, the in-core node and pager state would remain live because of the
reference from the kernel to the external-pager object. Conversely, with
the caching disabled in such a situation perhaps an in-core node would lose
all refs and be in the process of its cleanups when a new lookup created a
new in-core node, or some race like that. At any rate, the dynamics of
reference lifetimes vs time and sequence of other operations are changed by
this caching option.
