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. thanks, Mi Jinlong -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
