All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Mi Jinlong <mijinlong@cn.fujitsu.com>
Cc: Trond Myklebust <trond.myklebust@fys.uio.no>,
	Jeff Layton <jlayton@redhat.com>,
	NFSv3 list <linux-nfs@vger.kernel.org>,
	linux-fsdevel@vger.kernel.org, ebiederm@xmission.com,
	adobriyan@gmail.com, viro@ZenIV.linux.org.uk,
	jamie@shareable.org
Subject: Re: [PATCH] VFS: Unlink should revoke all outstanding leases on file
Date: Wed, 19 May 2010 11:57:00 -0400	[thread overview]
Message-ID: <20100519155700.GE4581@fieldses.org> (raw)
In-Reply-To: <4BF3B36F.80209@cn.fujitsu.com>

On Wed, May 19, 2010 at 05:46:23PM +0800, Mi Jinlong wrote:
> 
> 
> J. Bruce Fields :
> > On Fri, May 14, 2010 at 02:31:12PM -0400, Trond Myklebust wrote:
> >> On Fri, 2010-05-14 at 13:59 -0400, Trond Myklebust wrote: 
> >>> Note that the server should also recall the delegation if someone
> >>> attempts to violate the guarantees that are listed in section 9.4: Open
> >>> Delegation
> >>>
> >>>    When a client has a read open delegation, it may not make any changes
> >>>    to the contents or attributes of the file but it is assured that no
> >>>    other client may do so.  When a client has a write open delegation,
> >>>    it may modify the file data since no other client will be accessing
> >>>    the file's data.  The client holding a write delegation may only
> >>>    affect file attributes which are intimately connected with the file
> >>>    data:  size, time_modify, change.
> >>>
> >>> IOW: even if you hold a write delegation you are not allowed to change
> >>> the file mode bits, owner, group or acls...
> >> ...or the nlink value. So technically, we should also recall the
> >> delegation when someone creates or deletes a hard link. I think I need
> >> to remind Tom that he should add that to the RFC3530bis draft...
> > 
> > Yep.  And fixing all these cases is required before our the server's
> > NFSv4 server is ready for much of anything.
> > 
> > I'm not sure ading break_lease() to may_delete() is right, but maybe
> > it's better than nothing.
> 
>   Agree with you.
> 
> > 
> > One problem is that there's a race: nothing I can see stops anyone from
> > getting another lease after may_delete() but before the delete happens.
> 
>   Yes. 
>   The problem will exist, but there isn't some better methods to avoid it.
>   Is there a lease lock exist in kernel? 
>   If that's true, the problem will be fixed simply.

I don't know of any existing lock that does exactly what we want.

Somebody at citi worked on a better lease implementation for a while,
but I don't think we ever really got it right; the last version I can
find is here:

	git://linux-nfs.org/~bfields/linux-topics.git leases

--b.

  reply	other threads:[~2010-05-19 15:57 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-14  9:35 [PATCH] VFS: Unlink should revoke all outstanding leases on file Mi Jinlong
2010-05-14  9:35 ` Mi Jinlong
2010-05-14  9:58 ` Jeff Layton
2010-05-14  9:58   ` Jeff Layton
2010-05-14 17:17   ` Trond Myklebust
2010-05-14 17:38     ` Jeff Layton
2010-05-14 17:38       ` Jeff Layton
2010-05-14 17:46       ` Jamie Lokier
2010-05-14 17:46         ` Jamie Lokier
2010-05-14 18:16         ` Jeremy Allison
2010-05-19 14:06           ` J. Bruce Fields
2010-05-19 16:21             ` Jamie Lokier
2010-05-19 16:21               ` Jamie Lokier
2010-05-14 17:59       ` Trond Myklebust
2010-05-14 17:59         ` Trond Myklebust
2010-05-14 18:31         ` Trond Myklebust
2010-05-14 19:23           ` J. Bruce Fields
2010-05-14 19:23             ` J. Bruce Fields
2010-05-19  9:46             ` Mi Jinlong
2010-05-19  9:46               ` Mi Jinlong
2010-05-19 15:57               ` J. Bruce Fields [this message]
2010-05-20  9:46                 ` Mi Jinlong
2010-05-20  9:46                   ` Mi Jinlong
2010-05-21 21:07                   ` J. Bruce Fields
2010-05-21 21:07                     ` J. Bruce Fields
2010-05-25 10:14                     ` Mi Jinlong
2010-05-25 10:14                       ` Mi Jinlong
2010-05-19 16:14             ` Jamie Lokier
2010-05-20  2:21               ` J. Bruce Fields
2010-05-20  2:21                 ` J. Bruce Fields
     [not found]   ` <20100514055844.109d2fdc-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
2010-05-19  9:49     ` Mi Jinlong
2010-05-19  9:49       ` Mi Jinlong
2010-05-19 16:03       ` J. Bruce Fields
2010-05-20  9:23         ` Mi Jinlong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100519155700.GE4581@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=adobriyan@gmail.com \
    --cc=ebiederm@xmission.com \
    --cc=jamie@shareable.org \
    --cc=jlayton@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=mijinlong@cn.fujitsu.com \
    --cc=trond.myklebust@fys.uio.no \
    --cc=viro@ZenIV.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.