All of lore.kernel.org
 help / color / mirror / Atom feed
From: bugzilla-daemon@bugzilla.kernel.org
To: linux-ext4@kernel.org
Subject: [Bug 196405] mkdir mishandles st_nlink in ext4 directory with 64997 subdirectories
Date: Tue, 18 Jul 2017 23:15:40 +0000	[thread overview]
Message-ID: <bug-196405-13602-yO7S253Leg@https.bugzilla.kernel.org/> (raw)
In-Reply-To: <bug-196405-13602@https.bugzilla.kernel.org/>

https://bugzilla.kernel.org/show_bug.cgi?id=196405

--- Comment #8 from Paul Eggert (eggert@cs.ucla.edu) ---
(In reply to Theodore Tso from comment #1)
> In order to support a large
> number of directories, when we have a 16-bit link count field, we use
> a link count of 1 to mean, "lots".

Where is this behavior documented? I don't see it mentioned in
e2fsprogs/doc/libext2fs.texinfo. Where should I look?

> various userspace utilities that try to optimize
> directory walking by depending on the directory's link count to
> understand when they have found all of the subdirectories know that
> directory link count of 1 means "lots".

Although I've been contributing to the GNU core utilities for many years, this
behavior is news to me. I just checked the GNU coreutils source, and these
utilities do not know that 1 means "lots". Although the code happens to work,
it is pure luck. GNU findutils is similar.

The GNU C library's fts functions can misbehave on file systems where st_nlink
undercounts the number of subdirectories. To reproduce the problem, run the
program fts-test.c (attached to this bug report) in a fresh directory. On an
ext4 file system, the program outputs "0 needles found (should be 2)" and
fails, due to the incompatibility between ext4 st_nlink behavior and what the
GNU C library expects.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

  parent reply	other threads:[~2017-07-18 23:15 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-17 21:23 [Bug 196405] New: mkdir mishandles st_nlink in ext4 directory with 64997 subdirectories bugzilla-daemon
2017-07-18 19:41 ` [Bug 196405] " bugzilla-daemon
2017-07-18 21:07 ` bugzilla-daemon
2017-07-18 21:37 ` bugzilla-daemon
2017-07-18 21:54 ` bugzilla-daemon
2017-07-18 21:57 ` bugzilla-daemon
2017-07-18 22:19 ` bugzilla-daemon
2017-07-18 23:12 ` bugzilla-daemon
2017-07-18 23:15 ` bugzilla-daemon [this message]
2017-07-19  5:35 ` bugzilla-daemon
2017-07-19  8:02 ` bugzilla-daemon
2017-07-19 14:49 ` bugzilla-daemon
2017-07-19 19:44 ` bugzilla-daemon
2017-07-19 19:59 ` bugzilla-daemon
2017-07-19 22:22 ` bugzilla-daemon
2017-07-20  0:59 ` bugzilla-daemon
2017-07-21  7:48 ` bugzilla-daemon
2017-07-21  8:22 ` bugzilla-daemon
2017-07-21 15:25 ` bugzilla-daemon
2017-07-21 18:34 ` bugzilla-daemon
2017-07-21 21:14 ` bugzilla-daemon
2017-07-21 21:47 ` bugzilla-daemon
2017-07-22 14:41 ` bugzilla-daemon
2017-07-23 16:23 ` bugzilla-daemon
2017-07-23 22:55 ` bugzilla-daemon
2017-07-24 18:48 ` bugzilla-daemon
2017-07-25  8:56 ` bugzilla-daemon
2017-07-25  9:05 ` bugzilla-daemon

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=bug-196405-13602-yO7S253Leg@https.bugzilla.kernel.org/ \
    --to=bugzilla-daemon@bugzilla.kernel.org \
    --cc=linux-ext4@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.