Arla on FreeBSD

[Kostik Belousov]

On Thu, Feb 15, 2007 at 12:59:04PM +0100, Tomas Olsson wrote:
> Kostik Belousov <kostikbel at gmail.com> writes:
> > On Thu, Feb 15, 2007 at 11:16:00AM +0100, Tomas Olsson wrote:
> > > The interesting part is how we open and access the cache files, and from
> > > what context. arlad is in chroot() to avoid recursive lookups across /, and
> > > it seems like a good idea to avoid such lookups now too.
> > > 
> > > So the main question is how to properly do VOP_{LOOKUP,CREATE,WRITE} etc on
> > > cache files in this dual context world, without mixing identities in bad
> > > ways or confusing the OS too much.
> > > 
> > > The currently messed up code lives in
> > > http://cvsweb.stacken.kth.se/cvsweb.cgi/arla/nnpfs/bsd/
> > > 
> > > Most interesting is nnpfs_vnodeops-common.c (nnpfs_write_common()) and
> > > nnpfs_blocks.c (open_file())
> > 
> > I made really quick look at the places you mentioned. I have some
> > comment for open_file(). For FreeBSD >= 6.x, the right way to open vnode
> > from the kernel code is to use vn_open() (and then vn_close()) API.
> >
> Great! Sounds reasonable.
> 
> We currently open the cache files from nnpfs' VOPs, are there any risks
> (deadlock?) involved if one passes an absolute path to vn_open() in such a
> context?  I'd have liked to do use arlad's thread for this, but vput()
There, you already have nnpfs vnode locked. The right lock order for vnodes
is from root down by the tree. As such, you may end up with reversals, that
would result in deadlocks, IMHO.

> explicitly uses curthread deep down in namei. Also, users are not normally
> allowed to access the cache files directly so some OSes complain on such a
> lookup with user creds; would that be a problem here?
How is the user access to cache is disabled ? And what is the cache itself ?
Local filesystem (UFS) that stores your blocks in regular files ?

> Of course, we wouldn't have to worry about such things if we just kept the
> vnode handy for each cache block file. Maybe it's a price worth paying.

Then, you need to take some care of cached vnode lifecircle (e.g., even
keeping the vnode vref'ed would not prevent it from being recycled, so you
may end with dead vnode).

Also, as Robert pointed out in his email, you probably need to decide about
MP-safeness of nnpfs.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20070215/c886b58c/attachment.pgp