5

I was in the root direction, /, and I did ls -lah for whatever reason and looked at the folder sizes. I noticed that the folder lost+found has a size of 16K, while all of the other directories has a size of 4K. /dev, /proc, and /sys are different sizes as well, but lost+found was the one I was initially curious about.

People have pointed out that /dev is because it is a different file system, and that /proc and /sys are virtual file systems so they don't follow the same rules as a normal one.

Does anyone have an explanation for this (the lost+found directory)? From a quick Google I couldn't seem to find an answer

-rw-r--r--  1 root root  152 Jul  2 11:47 extlinux.conf
drwxr-xr-x  3 root root 4.0K Nov  7 01:51 home
lrwxrwxrwx  1 root root   30 Jul  2 11:47 initrd.img -> /boot/initrd.img-3.2.0-4-amd64
-r--r--r--  1 root root  32K Jul  2 11:47 ldlinux.sys
drwxr-xr-x 12 root root 4.0K Jul  2 11:46 lib
drwxr-xr-x  2 root root 4.0K Nov  7 01:43 lib64
drwx------  2 root root  16K Jul  2 11:44 lost+found
drwxr-xr-x  2 root root 4.0K Jul  2 11:46 media
drwxr-xr-x  2 root root 4.0K Dec 24  2014 mnt
drwxr-xr-x  4 root root 4.0K Nov 14 22:00 opt
dr-xr-xr-x 85 root root    0 Nov  9 19:51 proc
drwx------  3 root root 4.0K Nov 15 21:01 root
drwxr-xr-x 15 root root  480 Nov 15 23:26 run
drwxr-xr-x  2 root root 4.0K Nov  7 01:43 sbin

Edit: I see the question What does size of a directory mean in output of 'ls -l' command? which kind of answers the question, but all new directories I make are 4.0K and lost+found to my knowledge has never had any info in it to warrant a larger size (this is a relatively new install, no uncalled for shutdowns). Also, for clarification, the filesystem type is ext3.

Edit 2: These files may be more helpful to people that can actually interpret them, but they still doesn't explain why /run is different, but someone suggested that this is because it is mounted (verified with df -h). It's also created by the mklost+found command, but when that command is run the directory size is shown as 49K (12 blocks) instead of 16K (4 blocks). The mke2fs.c file explains the 16K file with the line if ((lpf_size += fs->blocksize) >= 16*1024), but not the 49k.

cutrightjm
  • 5,050
  • 4
  • 22
  • 32
  • 3
    It's simpler for fsck to just create a lost+found directory with more reserved space for found files than to expand it if/when needed. With some types of fs corruption, it may not even be possible or safe to expand the lost+found dir while fsck is fixing errors. – cas Nov 17 '15 at 04:52
  • @cas so 16K seems to be 4 blocks, where a standard directory is 1 block. Why would /dev and /proc be smaller than that.. it seems like that would just make things more difficult for the filesystem – cutrightjm Nov 17 '15 at 05:07
  • hundreds or thousands of small files. dir size is related to number of entries (files) in it, not to the files' sizes. can't see why you'd want to do that, though. – cas Nov 17 '15 at 05:07
  • 2
    unless you have a particular use for this information (e.g. you're a fs driver hacker or kernel hacker), i'd just file it away in the "vaguely interesting things that don't matter" basket. – cas Nov 17 '15 at 05:08
  • I do like cas reasoning. Often you would notice too that if a directory is used, and files are erased the size does not shrink back. – Rui F Ribeiro Nov 17 '15 at 05:26
  • @RuiFRibeiro This is another question (and may be related to the .trash) – Manu H Nov 17 '15 at 09:08
  • @ekaj proc is a virtual filesystem so the reported directory size is probably pretty meaningless. dev on a modern system is likely tmpfs which seems to report directory sizes differently from ext* – plugwash Nov 18 '15 at 06:27
  • @plugwash it's udev on my filesystem, but your point makes sense – cutrightjm Nov 18 '15 at 06:30

1 Answers1

2

@cas was correct in his assumption that "It's simpler for fsck to just create a lost+found directory with more reserved space for found files than to expand it if/when needed. With some types of fs corruption, it may not even be possible or safe to expand the lost+found dir while fsck is fixing errors."

I'm not sure why I didn't before, but if you consult the mklost+found man page it gives you this information:

mklost+found pre-allocates disk blocks to the lost+found directory so that when e2fsck(8) is being run to recover a filesystem, it does not need to allocate blocks in the filesystem to store a large number of unlinked files. This ensures that e2fsck will not have to allocate data blocks in the filesystem during recovery.

The deeper answer to the specific question, why the file size is 49,152 bytes (or 48 KiB, or 12 sectors) is somewhere in the files below. It's the reason I was so curious about, but I still haven't found it out (I can't read C very well). If someone has free time, and knows I, and can explain the why, I will accept your answer over this one:

Community
  • 1
cutrightjm
  • 5,050
  • 4
  • 22
  • 32