From: Mi Jinlong <mijinlong@cn.fujitsu.com>
To: "J. Bruce Fields" <bfields@fieldses.org>
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: Thu, 20 May 2010 17:46:06 +0800 [thread overview]
Message-ID: <4BF504DE.7010804@cn.fujitsu.com> (raw)
In-Reply-To: <20100519155700.GE4581@fieldses.org>
J. Bruce Fields :
> 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
When reading the code of the git, i found a patch which try to fix
the lease's problem, but only for unlink.
commit id: d5a08e556116c66fb60a448f805a40bf54314634
msg: "leases: break file leases on unlink."
In this patch, it seems only add break_lease() and some other functions
but seems don't avoid the problem of race. Or there is some different
at break_lease() with the community's kernel.
Can you give me some message about the new lease? Thanks.
thanks,
Mi Jinlong
WARNING: multiple messages have this Message-ID (diff)
From: Mi Jinlong <mijinlong-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
To: "J. Bruce Fields" <bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
Cc: Trond Myklebust
<trond.myklebust-41N18TsMXrtuMpJDpNschA@public.gmane.org>,
Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
NFSv3 list <linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org,
adobriyan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
viro-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org,
jamie-yetKDKU6eevNLxjTenLetw@public.gmane.org
Subject: Re: [PATCH] VFS: Unlink should revoke all outstanding leases on file
Date: Thu, 20 May 2010 17:46:06 +0800 [thread overview]
Message-ID: <4BF504DE.7010804@cn.fujitsu.com> (raw)
In-Reply-To: <20100519155700.GE4581-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
J. Bruce Fields :
> 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
When reading the code of the git, i found a patch which try to fix
the lease's problem, but only for unlink.
commit id: d5a08e556116c66fb60a448f805a40bf54314634
msg: "leases: break file leases on unlink."
In this patch, it seems only add break_lease() and some other functions
but seems don't avoid the problem of race. Or there is some different
at break_lease() with the community's kernel.
Can you give me some message about the new lease? Thanks.
thanks,
Mi Jinlong
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2010-05-20 9:46 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
2010-05-20 9:46 ` Mi Jinlong [this message]
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=4BF504DE.7010804@cn.fujitsu.com \
--to=mijinlong@cn.fujitsu.com \
--cc=adobriyan@gmail.com \
--cc=bfields@fieldses.org \
--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=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.