All of lore.kernel.org
 help / color / mirror / Atom feed
From: Neil Schemenauer <nas@arctrix.com>
To: linux-btrfs@vger.kernel.org
Subject: Btrfs st_nlink for directories
Date: Fri, 22 Jan 2010 20:28:12 -0600	[thread overview]
Message-ID: <20100123022812.GA16124@arctrix.com> (raw)

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

             reply	other threads:[~2010-01-23  2:28 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-23  2:28 Neil Schemenauer [this message]
2010-01-23 20:42 ` Btrfs st_nlink for directories Aneesh Kumar K. V
2010-01-24  0:33   ` Chris Mason

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100123022812.GA16124@arctrix.com \
    --to=nas@arctrix.com \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.