On Wed, 2025-09-10 at 21:30 +1000, NeilBrown wrote: > On Wed, 10 Sep 2025, Jeff Layton wrote: > > On Wed, 2025-09-10 at 08:37 +0100, Al Viro wrote: > > > > ... and see viro/vfs.git#work.persistency for the part of the queue that > > > > had order already settled down (I'm reshuffling the tail at the moment; > > > > hypfs commit is still in the leftovers pile - the whole thing used to > > > > have a really messy topology, with most of the prep work that used to > > > > be the cause of that topology already in mainline - e.g. rpc_pipefs > > > > series, securityfs one, etc.) > > > > > > Speaking of which, nfsctl series contains the following and I'd like to > > > make sure that behaviour being fixed there *is* just an accident... > > > Could nfsd folks comment? > > > > > > [PATCH] nfsctl: don't bump st_nlink of directory when creating a symlink in it > > > > > > > > > apparently blindly copied from mkdir... > > > > > > > > > Signed-off-by: Al Viro <viro@xxxxxxxxxxxxxxxxxx> > > > --- > > > diff --git a/fs/nfsd/nfsctl.c b/fs/nfsd/nfsctl.c > > > index bc6b776fc657..282b961d8788 100644 > > > --- a/fs/nfsd/nfsctl.c > > > +++ b/fs/nfsd/nfsctl.c > > > @@ -1181,7 +1181,6 @@ static int __nfsd_symlink(struct inode *dir, struct dentry *dentry, > > > inode->i_size = strlen(content); > > > > > > > > > d_add(dentry, inode); > > > - inc_nlink(dir); > > > fsnotify_create(dir, dentry); > > > return 0; > > > } > > > > That is increasing the link count on the parent because it's adding a > > dentry to "dir". The link count on a dir doesn't have much meaning, but > > why do we need to remove it here, but keep the one in __nfsd_mkdir? > > The link count in an inode is the number of links *to* the inode. > A symlink (or file etc) in a directory doesn't imply a link to that > directory (they are links "from" the directory, but those aren't counted). > A directory in a directory, on the other hand, does imply a link to the > (parent) directory due to the ".." entry. > > In fact the link count on a directory should always be 2 plus the number > of subdirectories (one for the name in the parent, one for "." in the > directory itself, and one for ".." in each subdirectory). Some "find" > style programs depend on that to a degree, though mostly as an > optimisation. > I'm having a hard time finding where that is defined in the POSIX specs. The link count for normal files is fairly well-defined. The link count for directories has always been more nebulous. I think we would be well-served by a clearly-defined meaning for the link count on a directory for Linux, because different filesystems do this differently today. Yours and Al's semantics seem fine (I don't have a real preference, tbh), but we should codify this in Documentation/ since it is unclear. -- Jeff Layton <jlayton@xxxxxxxxxx>
