Messages in this thread | | | Date | Fri, 6 Sep 2002 00:02:49 +0200 | From | Ragnar Kjørstad <> | Subject | Re: [reiserfs-dev] Re: [PATCH] sparc32: wrong type of nlink_t |
| |
On Thu, Sep 05, 2002 at 02:18:49PM -0700, jw schultz wrote: > I'm assuming for the moment that the discussion here is > about what to report to stat(2) and not how to deal with > internal overflow (which should produce an error). > > So what you are suggesting is that > <pseudocode> > if (i.i_nlink > ST_NLINK_MAX) > st.st_nlink = S_ISDIR(i.i_mode) ? 1 : ST_NLINK_MAX; > </pseudocode> > > I don't know the rationale for st_nlink == 1 on directories > but it seems to me the thing to do is st_nlink == 0 on > overflow regardless of type. This simplifies the logic and > eliminates the use a funky special value that gets in the > way of supporting growth.
I believe nlink for directories and files are used differently, and thus may have to be handled differently as well.
Amongs other things nlink on directories are used when traversing directory-trees. If nlink=4 on a directory there must be 2 sub-directories, and you can stop looking once you've found the two.
By giving the incorrect nlink-number, applications using this optimization will break.
Apperently some operatingsystems/filesystems (VMS?) report the special value of nlink=1 when the information is not available, and some applications use this information to automaticly disable the optimization. This is why reiserfs has returned nlink=1 for directories with more than MAX_REISERFS_NLINK subdirectories.
Now, I've just checked the source of GNU find (v4.1.7) and it does _not_ recognize nlink=1 as a special value. (It works as long as there are less than 2^32 subdirectories though, because it is looking for -1 subdirectories and it wraps)
I'm not sure exactly what nlink is used for in userspace for regular files, so I don't know what value should be used when the real number doesn't fit in the interface.
(Of course new directories/hardlinks shouldn't be created at all once the limit is exceeded, the above is only a workaround for people that need it anyway :) )
-- Ragnar Kjørstad - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |