On Thu, Jun 13, 2019 at 02:36:49PM +1000, Dave Chinner wrote: > On Wed, Jun 12, 2019 at 08:23:20PM -0700, Matthew Wilcox wrote: > > On Thu, Jun 13, 2019 at 10:25:55AM +1000, Dave Chinner wrote: > > > On Wed, Jun 12, 2019 at 05:37:53AM -0700, Matthew Wilcox wrote: > > > > That's rather different from the normal meaning of 'exclusive' in the > > > > context of locks, which is "only one user can have access to this at > > > > a time". > > > > > > Layout leases are not locks, they are a user access policy object. > > > It is the process/fd which holds the lease and it's the process/fd > > > that is granted exclusive access. This is exactly the same semantic > > > as O_EXCL provides for granting exclusive access to a block device > > > via open(), yes? > > > > This isn't my understanding of how RDMA wants this to work, so we should > > probably clear that up before we get too far down deciding what name to > > give it. > > > > For the RDMA usage case, it is entirely possible that both process A > > and process B which don't know about each other want to perform RDMA to > > file F. So there will be two layout leases active on this file at the > > same time. It's fine for IOs to simultaneously be active to both leases. > > Yes, it is. > > > But if the filesystem wants to move blocks around, it has to break > > both leases. > > No, the _lease layer_ needs to break both leases when the filesystem > calls break_layout(). That's a distinction without a difference as far as userspace is concerned. If process A asks for an exclusive lease (and gets it), then process B asks for an exclusive lease (and gets it), that lease isn't exclusive! It's shared. I think the example you give of O_EXCL is more of a historical accident. It's a relatively recent Linuxism that O_EXCL on a block device means "this block device is not part of a filesystem", and I don't think most userspace programmers are aware of what it means when not paired with O_CREAT. > > If Process C tries to do a write to file F without a lease, there's no > > problem, unless a side-effect of the write would be to change the block > > mapping, > > That's a side effect we cannot predict ahead of time. But it's > also _completely irrelevant_ to the layout lease layer API and > implementation.(*) It's irrelevant to the naming, but you brought it up as part of the semantics.
