Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 15 May 2002 10:06:36 -0700
From:      Alfred Perlstein <bright@mu.org>
To:        "Andrew R. Reiter" <arr@FreeBSD.org>
Cc:        Terry Lambert <tlambert2@mindspring.com>, Richard Sharpe <rsharpe@ns.aus.com>, freebsd-hackers@FreeBSD.org
Subject:   Re: File locking, closes and performance in a distributed filesystemenv
Message-ID:  <20020515170636.GI1585@elvis.mu.org>
In-Reply-To: <Pine.NEB.3.96L.1020515125325.98224B-100000@fledge.watson.org>
References:  <20020515155101.GF1585@elvis.mu.org> <Pine.NEB.3.96L.1020515125325.98224B-100000@fledge.watson.org>

next in thread | previous in thread | raw e-mail | index | archive | help
* Andrew R. Reiter <arr@FreeBSD.org> [020515 09:54] wrote:
> On Wed, 15 May 2002, Alfred Perlstein wrote:
> 
> :* Terry Lambert <tlambert2@mindspring.com> [020515 01:36] wrote:
> :> Alfred Perlstein wrote:
> :> > As Terry stated you can't do that, however you could cache that the
> :> > VNODE has a lock, that would reduce the requirement for calling the
> :> > ADVLOCK VOP.
> :> You'd really have to know when the lock list went to NULL, to get
> :> any benefit out of it, since locking would still end up being per-file
> :> sticky.  You could post-check after every successful unlock... but to
> :> cache the remote state would mean another RPC to ask for locks, which
> :> would just be front-loading the expense, instead of back-loading it.
> :
> :[snip]
> :
> :He could also maintain a local cache of this per vnode, basically
> :maintain a mirror of the lock list locally in order to see if a remote
> :op must be done.
> 
> Isn't this sorta like coda?

I'm not a coda expert so I wouldn't know, but I wasn't professing to
have invented something profound by suggesting a client cache. :)

-- 
-Alfred Perlstein [alfred@freebsd.org]
'Instead of asking why a piece of software is using "1970s technology,"
 start asking why software is ignoring 30 years of accumulated wisdom.'
Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020515170636.GI1585>