Matthew Dillon wrote:
> :>     Try using null mounts.  The warning is in there because making the
> :>     null mount code work is a real hack and the authors aren't entirely
> :>     sure that everything's gotten covered.  That said, use of a null mount
> :>     is certainly a lot safer if the stuff behind the mount is mostly
> :>     static.
> :
> :The problem is in the VM object alias code.  Specifically, the
> :getpages/putpages have to be implemented in terms of read/write,
> :so that there are not two vm_object_t's that refer to the same
> :data, since there is no "upcall" to notify of changes in a lower
> :layer, and therefore guarantee coherency.
> 
>     I'm fairly sure the VM issues were fixed when VOP_GETVOBJECT was
>     added.  A file accessed via a null mount will have the same VM object
>     as the file in the original filesystem.  I'm not 100% sure about
>     that, I wasn't the one who did it, but I seem to recall it being
>     discussed.

VOP_GETVOBJECT is a different name, but the VOP was my suggestion,
to allow an upper layer to obtain a backing object, and to
collapse intermediate layers.

The issue is that the NULLFS getpages falls through the the
vfs_default.c vop_stdgetpages(), which calls the function
vnode_pager_generic_getpages(), which in turn, calls VOP_BMAP(),
which in null_vnops.c is vop_eopnotsupp(), so it falls back to
vnode_pager_input_smlfs(), which VOP_BMAP()'s *again*, but off
the device.

At which point, you've lost coherency.

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Reply via email to