Etydhv

On my CentOS 7.6, I have created a folder (called many_files) with 3,000,000 files, by running:

for i in 1..3000000; do echo $i>$i; done;

I am using the command find to write the information about files in this directory into a file. This works surprisingly fast:

$ time find many_files -printf '%i %y %pn'>info_file

real 0m6.970s
user 0m3.812s
sys 0m0.904s

Now if I add %M to get the permissions:

$ time find many_files -printf '%i %y %M %pn'>info_file

real 2m30.677s
user 0m5.148s
sys 0m37.338s

The command takes much longer. This is very surprising to me, since in a C program we can use struct stat to get inode and permission information of a file and in the kernel the struct inode saves both these information.

My Questions:

1. What causes this behavior?


2. Is there a faster way to get file permissions for so many files?

The first version requires only to readdir(3)/getdents(2) the directory, when run on a filesystem supporting this feature (ext4: filetype feature displayed with tune2fs -l /dev/xxx, xfs: ftype=1 displayed with xfs_info /mount/point ...).

The second version in addition also requires to stat(2) each file, requiring an additional inode lookup, and thus more seeks on the filesystem and device, possibly quite slower if it's a rotating disk and cache wasn't kept. This stat is not required when looking only for name, inode and filetype because the directory entry is enough:

 The linux_dirent structure is declared as follows:

 struct linux_dirent 
 unsigned long d_ino; /* Inode number */
 unsigned long d_off; /* Offset to next linux_dirent */
 unsigned short d_reclen; /* Length of this linux_dirent */
 char d_name[]; /* Filename (null-terminated) */
 /* length is actually (d_reclen - 2 -
 offsetof(struct linux_dirent, d_name)) */
 /*
 char pad; // Zero padding byte
 char d_type; // File type (only since Linux
 // 2.6.4); offset is (d_reclen - 1)
 */
 

the same informations are available to readdir(3):

struct dirent 
 ino_t d_ino; /* Inode number */
 off_t d_off; /* Not an offset; see below */
 unsigned short d_reclen; /* Length of this record */
 unsigned char d_type; /* Type of file; not supported
 by all filesystem types */
 char d_name[256]; /* Null-terminated filename */
;

Suspected but confirmed by comparing (on a smaller sample...) the two outputs of:

strace -o v1 find many_files -printf '%i %y %pn'>info_file
strace -o v2 find many_files -printf '%i %y %M %pn'>info_file

Which on my Linux amd64 kernel 5.0.x just shows as main difference:

[...]

 getdents(4, /* 0 entries */, 32768) = 0
 close(4) = 0
 fcntl(5, F_DUPFD_CLOEXEC, 0) = 4
-write(1, "25499894 d many_filesn25502410 f"..., 4096) = 4096
-write(1, "iles/844n25502253 f many_files/8"..., 4096) = 4096
-write(1, "096 f many_files/686n25502095 f "..., 4096) = 4096
-write(1, "es/529n25501938 f many_files/528"..., 4096) = 4096
-write(1, "1 f many_files/371n25501780 f ma"..., 4096) = 4096
-write(1, "/214n25497527 f many_files/213n2"..., 4096) = 4096
-brk(0x55b29a933000) = 0x55b29a933000
+newfstatat(5, "1000", 0644, st_size=5, ..., AT_SYMLINK_NOFOLLOW) = 0
+newfstatat(5, "999", 0644, st_size=4, ..., AT_SYMLINK_NOFOLLOW) = 0
+newfstatat(5, "998", 0644, st_size=4, ..., AT_SYMLINK_NOFOLLOW) = 0
+newfstatat(5, "997", 0644, st_size=4, ..., AT_SYMLINK_NOFOLLOW) = 0
+newfstatat(5, "996", 0644, st_size=4, ..., AT_SYMLINK_NOFOLLOW) = 0
+newfstatat(5, "995", 0644, st_size=4, ..., AT_SYMLINK_NOFOLLOW) = 0
+newfstatat(5, "994", 0644, st_size=4, ..., AT_SYMLINK_NOFOLLOW) = 0
+newfstatat(5, "993", 0644, st_size=4, ..., AT_SYMLINK_NOFOLLOW) = 0
+newfstatat(5, "992", 0644, st_size=4, ..., AT_SYMLINK_NOFOLLOW) = 0
+newfstatat(5, "991", 0644, st_size=4, ..., AT_SYMLINK_NOFOLLOW) = 0
+newfstatat(5, "990", 0644, st_size=4, ..., AT_SYMLINK_NOFOLLOW) = 0

[...]

+newfstatat(5, "891", 0644, st_size=4, ..., AT_SYMLINK_NOFOLLOW) = 0
+write(1, "25499894 d drwxr-xr-x many_files"..., 4096) = 4096
+newfstatat(5, "890", 0644, st_size=4, ..., AT_SYMLINK_NOFOLLOW) = 0

[...]

For your 1st question:

I think your problem is not with how quickly the information is accessed, but the output bottleneck.

You are writing the output to info_file.

When you add %M to the find command, you are now outputting more text due to the permissions. 10 additional characters per line of output. That is 30,000,000 more characters.

This is more data that has to go through the STDOUT redirect to info_file and get written to disk. More data to push == longer time to write and complete.

In a situation with a single file or a small number of files, it would not be noticeable to a human; time may give you some variation to measure but it might be too slight to notice.

In your question you are working with 3,000,000 files, so obviously it takes longer to write out the permissions output.

2nd question

I have no idea. Do you have a practical use case for needing to collect permissions for 3,000,000 files, or is this an academic exercise?