Btrfs st_nlink for directories

Hi,

It looks like Btrfs does not follow Unix traditions for st_nlink attribute of directories. It seems to be always one, no matter the number of sub-directories.

Is this intentional? I couldn't find it discussed anywhere. I gather the Mac OS HFS+ doesn't follow traditional st_nlink behavior as well. The 'find' man page has this note:

-noleaf
Do not optimize by assuming that directories contain 2 fewer
subdirectories than their hard link count. This option is
needed when searching filesystems that do not follow the Unix directory-link convention, such as CD-ROM or MS-DOS filesystems or AFS volume mount points. Each directory on a normal Unix filesystem has at least 2 hard links: its name and its `.'
entry. Additionally, its subdirectories (if any) each have a
`..' entry linked to that directory. When find is examining a directory, after it has statted 2 fewer subdirectories than the directory's link count, it knows that the rest of the entries in the directory are non-directories (`leaf' files in the directory tree). If only the files' names need to be examined, there is no need to stat them; this gives a significant increase in search speed.

Regards,

Neil

I have sent patches with message-id 1264279089-14913-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com to the list. Let me know if they works for your

-aneesh

Thanks for taking a look at this Aneesh, but in btrfs we always have a link count of one on directories.

It's a design decision so that we don't end up limited in the total number of subdirs we can create. reiser3 did something similar, switching to 1 when the link count got high. I think the other filesystems may have added something along these lines as well by now.

Btrfs just leaves it at one all the time.

-chris