0

By the following question:

Is there some universally recommended Reserved block count (for root) for large Ext4 drives?

I specifically mean the following:

  • Let us consider (almost) everyone has a rather large root drive (partition) nowadays.

  • Let us consider for example 2TB drive with a 1.8TiB root partition, meaning the whole drive is used, except for the 1st boot partition.

  • Further, let us assume only I have access to this computer and that I have direct access to HW, and OS.

  • As an addition I have set in GRUB: GRUB_CMDLINE_LINUX_DEFAULT="rootflags=data=journal", the particular documentation I did not manage to find, feel free to add it here.

To put all this into a working example, here is my NVMe drive in my laptop:

# fdisk -l /dev/nvme0n1

Disk /dev/nvme0n1: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: Samsung SSD 970 EVO Plus 2TB

Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 989573D5-37E7-437A-B680-9410F7234A94


Device          Start        End    Sectors  Size Type
/dev/nvme0n1p1   2048     194559     192512   94M EFI System
/dev/nvme0n1p2 194560 3907028991 3906834432  1.8T Linux filesystem

The 2nd partition /dev/nvme0n1p2 is of Ext4 filesystem type, and here is the full list of values considering it:

# tune2fs -l /dev/nvme0n1p2 
tune2fs 1.46.5 (30-Dec-2021)
Filesystem volume name:   <none>
Last mounted on:          /
Filesystem UUID:          f1fc7345-be7a-4c6b-9559-fc6e2d445bfa
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              122093568
Block count:              488354304
Reserved block count:     20068825
Free blocks:              388970513
Free inodes:              121209636
First block:              0
Block size:               4096
Fragment size:            4096
Group descriptor size:    64
Reserved GDT blocks:      817
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Sat Jun 16 11:26:24 2018
Last mount time:          Thu Oct 26 09:14:38 2023
Last write time:          Thu Oct 26 09:14:38 2023
Mount count:              102
Maximum mount count:      -1
Last checked:             Tue Sep 26 03:05:31 2023
Check interval:           0 (<none>)
Lifetime writes:          43 TB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:           256
Required extra isize:     32
Desired extra isize:      32
Journal inode:            8
First orphan inode:       134214
Default directory hash:   half_md4
Directory Hash Seed:      48360d76-0cfb-4aed-892e-a8f3a30dd794
Journal backup:           inode blocks
Checksum type:            crc32c
Checksum:                 0x58d12a63

I would like to evaluate if I need some reserved root space, and if yes, how much. I would like this question not to be opinion-based, so if you decide to add an answer please include some references, thank you.

Vlastimil Burián
  • 28,462

1 Answers1

2

So, there's few reasons that count exists, at all.

The easiest reason is that you would want a root-run service that saves logs and or data to that volume to continue to work even if a user floods the drive with dat. This obviously is only relevant when

  1. the volume you're referring to actually is used by root-running processes, and
  2. it is also used by users who should not be able to deny operation of these services by filling the disk with files, and
  3. it is more important that services continue to function than that unprivileged users are able to write user data.

Yours seems to be a desktop system, so at the very least, I'd say 3. is questionable, if not the exact opposite of what you need.

So, I consider that a very weak argument, especially because many services these days don't run as root to begin with.

Then, the other argument (here brought forward by the "main" developer of ext4) is that the not having much free space makes it harder for the file system to find contiguous areas of blocks to use for new or growing files. That leads to so-called fragmentation, which was a hardware performance issue on rotating disk storage (due to large seek times) and still is an overhead issue due to the much more complicated and redirective ways files that are fragmented are stored and read. The file system driver needs to make a file that is scattered all over your storage look contiguous to the application, and that at the end comes at the expense of ability to prefetch and cache; still a minor concern on SSDs. It also increases metadata size. I'm not versed enough in ext4's internal structures to tell you whether this increased need for metadata reduces the available space or just means more lookups when accessing a fragmented file.

https://listman.redhat.com/archives/ext3-users/2009-January/msg00026.html

If you set the reserved block count to zero, it won't affect performance much except if you run for long periods of time (with lots of file creates and deletes) while the filesystem is almost full (i.e., say above 95%), at which point you'll be subject to fragmentation problems

[…]

If you are just using the filesystem for long-term archive, where files aren't changing very often (i.e., a huge mp3 or video store), it obviously won't matter.

So, it really depends on your use case. Seeing that your file system was mounted at /, it's probably the file system where all your installed software resides – and large software updates are exactly these periods of mass deletion and creation of files. So, reserving enough space so that, on average, when the sizes of created and deleted files are in balance, you're free to chose from enough contiguous parts of your storage, makes sense.

So, how much would that be? Hard to tell. But say, a large update process doing maybe 20 GB (10 GB of new files, 10 GB of old files getting deleted afterwards) of changes would seem realistically a sensible upper bound. So, that would seem to be a good value for reserved space.

Your file system is 1.86 TB in size, which means your NVMe is probably a consumer/prosumer 1.92TB device. These currently run at 45 to 80€ per TB. I recommend mentally checking whether even thinking about "optimizing" the reserved space is worth your mental headspace, monetarily. Sure, 78 GB is probably much more than you'll need, but do you care enough to find out whether less actually suffices if this equates to less than 6.60€ in storage space?

Marcus Müller
  • 28,836