On Wed, Aug 14, 2019 at 07:21:34AM -0400, Jeff Layton wrote: > On Wed, 2019-08-14 at 18:05 +1000, Dave Chinner wrote: > > On Mon, Aug 12, 2019 at 10:36:26AM -0700, Ira Weiny wrote: > > > On Sat, Aug 10, 2019 at 09:52:31AM +1000, Dave Chinner wrote: > > > > On Fri, Aug 09, 2019 at 03:58:15PM -0700, ira.weiny@xxxxxxxxx wrote: > > > > > + /* > > > > > + * NOTE on F_LAYOUT lease > > > > > + * > > > > > + * LAYOUT lease types are taken on files which the user knows that > > > > > + * they will be pinning in memory for some indeterminate amount of > > > > > + * time. > > > > > > > > Indeed, layout leases have nothing to do with pinning of memory. > > > > > > Yep, Fair enough. I'll rework the comment. > > > > > > > That's something an application taht uses layout leases might do, > > > > but it largely irrelevant to the functionality layout leases > > > > provide. What needs to be done here is explain what the layout lease > > > > API actually guarantees w.r.t. the physical file layout, not what > > > > some application is going to do with a lease. e.g. > > > > > > > > The layout lease F_RDLCK guarantees that the holder will be > > > > notified that the physical file layout is about to be > > > > changed, and that it needs to release any resources it has > > > > over the range of this lease, drop the lease and then > > > > request it again to wait for the kernel to finish whatever > > > > it is doing on that range. > > > > > > > > The layout lease F_RDLCK also allows the holder to modify > > > > the physical layout of the file. If an operation from the > > > > lease holder occurs that would modify the layout, that lease > > > > holder does not get notification that a change will occur, > > > > but it will block until all other F_RDLCK leases have been > > > > released by their holders before going ahead. > > > > > > > > If there is a F_WRLCK lease held on the file, then a F_RDLCK > > > > holder will fail any operation that may modify the physical > > > > layout of the file. F_WRLCK provides exclusive physical > > > > modification access to the holder, guaranteeing nothing else > > > > will change the layout of the file while it holds the lease. > > > > > > > > The F_WRLCK holder can change the physical layout of the > > > > file if it so desires, this will block while F_RDLCK holders > > > > are notified and release their leases before the > > > > modification will take place. > > > > > > > > We need to define the semantics we expose to userspace first..... > > Absolutely. > > > > > > > Agreed. I believe I have implemented the semantics you describe above. Do I > > > have your permission to use your verbiage as part of reworking the comment and > > > commit message? > > > > Of course. :) > > > > Cheers, > > > > I'll review this in more detail soon, but subsequent postings of the set > should probably also go to linux-api mailing list. This is a significant > API change. It might not also hurt to get the glibc folks involved here > too since you'll probably want to add the constants to the headers there > as well. Sure, but lets first get it to the point where we have something that is actually workable, much more complete and somewhat validated with unit tests before we start involving too many people. Wide review of prototype code isn't really a good use of resources given how much it's probably going to change from here... > Finally, consider going ahead and drafting a patch to the fcntl(2) > manpage if you think you have the API mostly nailed down. This API is a > little counterintuitive (i.e. you can change the layout with an F_RDLCK > lease), so it will need to be very clearly documented. I've also found > that when creating a new API, documenting it tends to help highlight its > warts and areas where the behavior is not clearly defined. I find writing unit tests for xfstests to validate the new APIs work as intended finds far more problems with the API than writing the documentation. :) Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
