Hard link count reported by "ls -l" is wrong

Hard link count reported by "ls -l" is wrong

[Franklin, Jason]

Greetings:

I'm using btrfs on Debian 10.

When using "ls -l" to view a detailed listing in the current directory,
I get output similar to the following:

total 0
drwxrwx--- 1 jfrankli jfrankli  38 Feb 25 09:54 Desktop/
drwxrwx--- 1 jfrankli jfrankli  36 Jan 24 10:37 Documents/
drwxrwx--- 1 jfrankli jfrankli 612 Feb 24 15:48 Downloads/
drwxrwx--- 1 jfrankli jfrankli   0 Nov  6 04:44 Music/
drwxrwx--- 1 jfrankli jfrankli  20 Nov  6 04:44 Pictures/
drwxrwx--- 1 jfrankli jfrankli   0 Nov  6 04:44 Public/
drwxrwx--- 1 jfrankli jfrankli   0 Dec 27 20:20 Templates/
drwxrwx--- 1 jfrankli jfrankli   0 Dec 27 20:20 Videos/
drwxrwx--- 1 jfrankli jfrankli 522 Nov 26 09:53 bin/
drwxrwx--- 1 jfrankli jfrankli  28 Dec 27 15:23 snap/

Notice that these are all directories with a hard link count of "1".

I have always seen directories possessing a hard link count of "2" or
greater.  This is because the directory itself is a hard link, and it
also contains the "." entry (the second hard link).

Any immediate child directory of a directory also adds +1 to the hard
link count on other file systems.  This is because each child directory
contains the ".." hard link pointing to its parent directory.

Why does this not happen with btrfs?

Could it a bug with the GNU "ls" tool?

-- 
Jason Franklin

Re: Hard link count reported by "ls -l" is wrong

[Adam Borowski]

On Tue, Feb 25, 2020 at 09:59:49AM -0500, Franklin, Jason wrote:
> When using "ls -l" to view a detailed listing in the current directory,
> I get output similar to the following:

> drwxrwx--- 1 jfrankli jfrankli  38 Feb 25 09:54 Desktop/
> drwxrwx--- 1 jfrankli jfrankli  36 Jan 24 10:37 Documents/

> Notice that these are all directories with a hard link count of "1".
> 
> I have always seen directories possessing a hard link count of "2" or
> greater.  This is because the directory itself is a hard link, and it
> also contains the "." entry (the second hard link).

That's an implementation detail of filesystems on truly ancient Unices
(from the times before my birth -- and, with bearing kids at age 14 being
semi-popular these days, I could have been a great-grandfather).  And there,
indeed, subdirectories and ".." (not ".") had been implemented as actual
hard links.  Heck, you could even unlink() them with nasty results for the
filesystem -- remnants for such unlinking (but not the lore) can still be
seen in "perldoc -f unlink" and "man 2 unlink".

> Any immediate child directory of a directory also adds +1 to the hard
> link count on other file systems.  This is because each child directory
> contains the ".." hard link pointing to its parent directory.
> 
> Why does this not happen with btrfs?

Most filesystems emulate that behaviour.  For btrfs, such emulation would
have a bad effect for performance (the kernel would need to either count
subdirectories every time, or store and keep updated such count), thus
this value has been skipped.

And POSIX allows such behaviour.

Heck, if not for POSIX declaring some fields (st_nlink, st_rdev, st_size,
st_blksize and st_blocks) as not required to be meaningful, ext4 would be in
a violation of the spec as it gives st_size of an empty directory as
non-zero. :)


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ We domesticated dogs 36000 years ago; together we chased
⣾⠁⢰⠒⠀⣿⡁ animals, hung out and licked or scratched our private parts.
⢿⡄⠘⠷⠚⠋⠀ Cats domesticated us 9500 years ago, and immediately we got
⠈⠳⣄⠀⠀⠀⠀ agriculture, towns then cities.     -- whitroth on /.

Re: Hard link count reported by "ls -l" is wrong

[David Sterba]

On Tue, Feb 25, 2020 at 09:59:49AM -0500, Franklin, Jason wrote:
> Greetings:
> 
> I'm using btrfs on Debian 10.
> 
> When using "ls -l" to view a detailed listing in the current directory,
> I get output similar to the following:
> 
> total 0
> drwxrwx--- 1 jfrankli jfrankli  38 Feb 25 09:54 Desktop/
> drwxrwx--- 1 jfrankli jfrankli  36 Jan 24 10:37 Documents/
> drwxrwx--- 1 jfrankli jfrankli 612 Feb 24 15:48 Downloads/
> drwxrwx--- 1 jfrankli jfrankli   0 Nov  6 04:44 Music/
> drwxrwx--- 1 jfrankli jfrankli  20 Nov  6 04:44 Pictures/
> drwxrwx--- 1 jfrankli jfrankli   0 Nov  6 04:44 Public/
> drwxrwx--- 1 jfrankli jfrankli   0 Dec 27 20:20 Templates/
> drwxrwx--- 1 jfrankli jfrankli   0 Dec 27 20:20 Videos/
> drwxrwx--- 1 jfrankli jfrankli 522 Nov 26 09:53 bin/
> drwxrwx--- 1 jfrankli jfrankli  28 Dec 27 15:23 snap/
> 
> Notice that these are all directories with a hard link count of "1".
> 
> I have always seen directories possessing a hard link count of "2" or
> greater.  This is because the directory itself is a hard link, and it
> also contains the "." entry (the second hard link).
> 
> Any immediate child directory of a directory also adds +1 to the hard
> link count on other file systems.  This is because each child directory
> contains the ".." hard link pointing to its parent directory.
> 
> Why does this not happen with btrfs?
> 
> Could it a bug with the GNU "ls" tool?

No, link count 1 for directories is valid, btrfs does not implement
exact tracking like other filesystems.

https://btrfs.wiki.kernel.org/index.php/Project_ideas#Track_link_count_for_directories

Re: Hard link count reported by "ls -l" is wrong

[Qu Wenruo]

[-- Attachment #1.1: Type: text/plain, Size: 1823 bytes --]



On 2020/2/25 下午10:59, Franklin, Jason wrote:
> Greetings:
> 
> I'm using btrfs on Debian 10.
> 
> When using "ls -l" to view a detailed listing in the current directory,
> I get output similar to the following:
> 
> total 0
> drwxrwx--- 1 jfrankli jfrankli  38 Feb 25 09:54 Desktop/
> drwxrwx--- 1 jfrankli jfrankli  36 Jan 24 10:37 Documents/
> drwxrwx--- 1 jfrankli jfrankli 612 Feb 24 15:48 Downloads/
> drwxrwx--- 1 jfrankli jfrankli   0 Nov  6 04:44 Music/
> drwxrwx--- 1 jfrankli jfrankli  20 Nov  6 04:44 Pictures/
> drwxrwx--- 1 jfrankli jfrankli   0 Nov  6 04:44 Public/
> drwxrwx--- 1 jfrankli jfrankli   0 Dec 27 20:20 Templates/
> drwxrwx--- 1 jfrankli jfrankli   0 Dec 27 20:20 Videos/
> drwxrwx--- 1 jfrankli jfrankli 522 Nov 26 09:53 bin/
> drwxrwx--- 1 jfrankli jfrankli  28 Dec 27 15:23 snap/
> 
> Notice that these are all directories with a hard link count of "1".
> 
> I have always seen directories possessing a hard link count of "2" or
> greater.  This is because the directory itself is a hard link, and it
> also contains the "." entry (the second hard link).

It's fs dependent on if "." and ".." should be accounted to nlinks.

For btrfs, there is no need to both "." and "..", as they are all
handled by VFS, thus no need to do extra accounting.

So btrfs choose to use straightforward nlink number, only increase the
nlink if there is a hard link.

And for regular directory, no hard link is allowed, thus it's always 1.

Thanks,
Qu

> 
> Any immediate child directory of a directory also adds +1 to the hard
> link count on other file systems.  This is because each child directory
> contains the ".." hard link pointing to its parent directory.
> 
> Why does this not happen with btrfs?
> 
> Could it a bug with the GNU "ls" tool?
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]