On Mon, 2024-03-18 at 09:25 +0100, Stefan Metzmacher wrote: > Hi Jeff, > > > In order to add directory delegation support, we need to break > > delegations on the parent whenever there is going to be a change in the > > directory. > > > > Add a delegated_inode parameter to lookup_open and have it break the > > delegation. Then, open_last_lookups can wait for the delegation break > > and retry the call to lookup_open once it's done. > > > > Signed-off-by: Jeff Layton <jlayton@xxxxxxxxxx> > > --- > > fs/namei.c | 22 ++++++++++++++++++---- > > 1 file changed, 18 insertions(+), 4 deletions(-) > > > > diff --git a/fs/namei.c b/fs/namei.c > > index f00d8d708001..88598a62ec64 100644 > > --- a/fs/namei.c > > +++ b/fs/namei.c > > @@ -3404,7 +3404,7 @@ static struct dentry *atomic_open(struct nameidata *nd, struct dentry *dentry, > > */ > > static struct dentry *lookup_open(struct nameidata *nd, struct file *file, > > const struct open_flags *op, > > - bool got_write) > > + bool got_write, struct inode **delegated_inode) > > Does NFS has a concept of lease keys and parent lease keys? > > In SMB it's possible that the client passes a lease key (16 client chosen bytes) to a directory open, > when asking for a directory lease. > > Then operations on files within that directory, take that lease key from the directory as > 'parent lease keys' in addition to a unique lease key for the file. > > That way a client can avoid breaking its own directory leases when creating/move/delete... files > in the directory. > No, it's a bit different with NFSv4 directory delegations. A delegation is given vs a filehandle (which is analogous to an inode), and it gets a stateid, which just uniquely identifies it. There is no real association with the parent. When you request the dir delegation, you can request to be notified when something changes instead of the server recalling it. The server may or may not grant that request. Notifications are not implemented in this patchset as of yet. I'm focusing on getting the recall handling right first, and then I'll plan to add that in a later phase. -- Jeff Layton <jlayton@xxxxxxxxxx>
