Date: 15 Feb 2007 15:56:38 +0100 From: Tomas Olsson <tol@it.su.se> To: Kostik Belousov <kostikbel@gmail.com> Cc: freebsd-fs@freebsd.org, arla-drinkers@stacken.kth.se Subject: Re: Arla on FreeBSD Message-ID: <lsr8xez5v15.fsf@kashyyyk.ite.kth.se> In-Reply-To: <20070215134608.GG39168@deviant.kiev.zoral.com.ua> References: <20070214162938.GA96725@keira.kiwi-computer.com> <20070214173211.L1054@chrishome.localnet> <20070214170808.GC96725@keira.kiwi-computer.com> <lsrvei45pq1.fsf@kashyyyk.ite.kth.se> <20070215044707.GA39168@deviant.kiev.zoral.com.ua> <lsrmz3f680v.fsf_-_@kashyyyk.ite.kth.se> <20070215104537.GC39168@deviant.kiev.zoral.com.ua> <lsrhctn6393.fsf@kashyyyk.ite.kth.se> <20070215120855.GE39168@deviant.kiev.zoral.com.ua> <lsrd54b603c.fsf@kashyyyk.ite.kth.se> <20070215134608.GG39168@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
Kostik Belousov <kostikbel@gmail.com> writes:
> On Thu, Feb 15, 2007 at 02:07:19PM +0100, Tomas Olsson wrote:
> > Ok, vn_open() must be passed curthread so we can't use arlad's thread when
> > in our VOP. And we cannot use an absolute path to the cache. So vn_open()
> > can't be used?
> vn_open() does not need curthread in strong sence, but td is the thread
> that all locks and sleeps will be performed for.
>
Except in places like vput() and vrele()?
struct thread *td = curthread; /* XXX */
> I think that your current strategy would work, but it needs to be checked.
>
Nice. Possibly there are still a few places where I mix contexts too much
as well. And I've probably missed a few mandatory support routines along
the lines of vn_start_write().
> > So where does this leave us, is plain lookup() (or VOP_LOOKUP) and
> > VOP_CREATE on the cache a possible way to go? Seems to work on OpenBSD.
> vn_open() is the right way. Otherwise, you would in fact reimplement the
> code from it.
>
I know, I just don't see how to get around it.
> Also, you could look at file handle API, that would save you of path lookups
> after the vnode is looked up first time (look around for vfs_vptofh and
> vfs_fhtovp ops). This API is used by NFS server, so it shall work :).
>
That's an idea. We used that before in another context, but then we ran
into trouble with too many OSes so we dropped it. Depends on how much code
one can share.
> > Well, it's marked "doesn't need giant"; we use our own global lock. I don't
> > trust it 100%, but it seems to work so far. I haven't tried it on any MP
> > FreeBSD boxes though.
>
> Again, this could lead to lock order reversals with vnode lock. For
> instance, when lookup() traverses tree, it has the parent directory
> locked and calls fs-provided VOP_LOOKUP(). This method shall return the
> leaf vnode locked. Since, according to you claim, some alra-specific
> global lock is taken between these two vnode locks, it could LOR between
> vnode locks and alra lock
>
I'm not sure if that's currently a problem for us, but I'll take a
look. I'm sure there are other cases.
thanks
/t
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?lsr8xez5v15.fsf>