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:
signature.asc
Description: OpenPGP digital signature
