Btrfs st_nlink for directories

[Neil Schemenauer]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Aneesh Kumar K. V]

Post by Neil Schemenauer
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

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

-aneesh


--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Chris Mason]

Post by Aneesh Kumar K. V

Post by Neil Schemenauer
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

I have sent patches with message-id
to the list. Let me know if they works for your

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

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html