Date: Tue, 5 Dec 2000 10:40:20 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: ilya@xosoft.com (Ilya Usvyatsky) Cc: freebsd-fs@FreeBSD.ORG (FreeBSD-FS Mailing List) Subject: Re: VFCF_LOOPBACK flag Message-ID: <200012051040.DAA27828@usr05.primenet.com> In-Reply-To: <3A2CC0FF.79EEB4FB@xosoft.com> from "Ilya Usvyatsky" at Dec 05, 2000 12:18:40 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> Hi ppl,
> I am implementing (actually, porting from Solaris) now some
> special-purpose stackable file system.
> This FS stacks transparently over existing sub-tree of any 'real' FS and
> provides some special
> functionality via ioctl() calls.
> Here is a question that arised to me regarding the VFCF_LOOPBACK flag.
> The comment in <sys/mount.h> states that this flag means that the FS is
> aliasing some other one.
> On the other hand, in my case no aliasing is done (since I'm mounting
> transparently and do not
> create new name space). So, should I specify the flag in VFS_SET()
> macro?
The flags should be set.
The need for the flag is the result of the fact that the vnode
object in each VFS layer will, by definition, have its own
vmobject_t, which means that the cache coherency has to be
explicit, rather than being assumed as a result of the VM and
buffer cache unification.
See the NULLFS code changes with regart to VOP_{GET|PUT}PAGES(),
since this flag doesn't really work like it's supposed to work.
Really, the upper level paging code wants to operate against the
loweset level backing object before a translation, proxy, or
other operation which means that the backing object pages aren't
laid out the same as the underlying vnode in an inferior stack.
But set it anyway, incase this is ever fixed.
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200012051040.DAA27828>