Re: File system awareness (or lack thereof) of vfs granting of leases

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Feb 20, 2007 at 03:25:08PM -0600, David Teigland wrote:
> On Tue, Feb 20, 2007 at 03:51:54PM -0500, bfields@xxxxxxxxxxxx wrote:
> > > On Tue, Feb 20, 2007 at 10:46:51AM -0500, Robert Rappaport wrote:
> > > We did an experimental distributed lease implementation in gfs(1) a while
> > > ago.  It worked, but was so extremely expensive that there was no point in
> > > considering it seriously.  The problem is that _every_ open and close of
> > > every file requires a new dlm lock operation.  Leases require knowledge
> > > about the cluster-wide opened/closed state of files, not only that but the
> > > mode they're open in.
> > 
> > We're using leases to implement NFSv4 delegations.  Delegations are
> > similar to leases--they come in read and write variants, and they give
> > clients a guarantee that they'll be warned before another client is
> > allowed to do a conflicting open--but delegations are completely optional.
> >  A server can deny a delegation for any reason, even when there isn't
> > necessarily a conflicting open.
> > 
> > So perhaps we need some way for nfsd to ask the filesystem to give it a
> > lease, but only if it's easy to do so.  Would it be possible to make it
> > cheap for GFS to give out leases in some particular (hopefully common)
> > cases?
> 
> I don't know of any shortcuts off hand, but there could certainly be some.
> Doing something completely different and not using cluster locks may also
> be worth investigating.

I'm also curious--exposing my total ignorance of the dlm--why taking
such a lock would always be so expensive, or would always be required on
open.  Surely the typical case should be one where there's no conflict
and never has been, in which case asking for the lock you need should be
a trivial local operation?

--b.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux