Ext4 users - remember to reduce reserved blocks!

By default ext4 reserves 5% of your disk for the root user. That made sense in 1999, but that’s insane now. You can run this command (as root) to reduce reserved blocks to around 4GB. On a 16TB ext4 file-system that will free up 795GB (since the default of 5% reserved = 800GB reserved for root!).

tune2fs -r 1000000 /dev/<disk-device>

This instantly frees up the space. You don’t need to unmount or remount or restart or anything.

But first use “lsblk” and “df” commands to identify the ext4 file-systems to tune.

And be careful! Running any command directly against any /dev/<disk-device> file as root is always dangerous. Practice on a computer/drive that’s not important first.


Wouldn’t this be better? You just do it by percentage and tell it to reduce reserved space to 0%:

tune2fs -m 0 /dev/yourdrive


I knew this now you mention it but completely forgot about it. Thank you both; you’ve just bought me a few hours more plotting before my next batch of Western Digital Elements drives turn up from the nice Amazon man.

1 Like

A good reminder, but storage_jm has already documented the optimal way to format “final destination” drives since March:

sudo mkfs.ext4 -m 0 -T largefile4 -L <drivename> /dev/sdX

Very good point! Now that I think about it, reserved blocks really only make sense for the “/” partition (and I guess /var if it’s a separate mount). For everything else it’s just silly!

Oh yeah! I forgot I did this. That’s why tune2fs didn’t do anything :laughing:


while we’re talking about linux filesystem things…

Don’t just assume that just because it’s 2021 linux will handle TRIM for you at mount.

You need to actually either setup a very frequent trimfs cron job, or mount with discard. You need to use a filesystem that actually supports it (not exfat).

I wasted a lot of time trying to figure out why my plots were running so slowly. Turns out my ssd was deeply disoriented, because trim wasn’t running at all.


This is all great info that I had previously missed. Thanks for sharing!

1 Like

Edit: I didn’t see topic and created my own thread. Basically the same thing that everyone else has seen. Gained back 5% of my plot drives.

FYI if you’re using ext4 as the format of your destination drives, or even tmp drives that get close to 100% capacity, If you used the defaults when formatting the drive it will reserve 5% of the capacity of the partition for root process purposes.

If you aren’t using the partition for your Linux root/home directory you can bump this reserved space down to 0 and shouldn’t run into issues, adding 5% capacity for storing more plots.

To check if you have reserved blocks on a plot drive, these were the commands I found useful:

Get the list of partitions:
df -h

For each partition that’s ext4 run this to check if there are reserved blocks:
tune2fs -l /dev/partition | grep 'Reserved'

Finally, use tune2fs to set the reserve blocks to 0:
tune2fs -r 0 /dev/partition

As far as I can tell this is safe to run and will not reformat the drive (I did it without problems AFAIK).

If you’re starting from an empty drive, you can use the -m parameter to set the % of blocks reserved to 0.


More discussion on that here:


Thank you - this was super helfpul!

To be fair, trim was running but weekly rather than daily. From this:

I learned that fstrim is managed by systemctl.

the command:
systemctl status fstrim.timer
reveals how often trim is set to run

and by editing my fstrim.timer file:
sudo nano /usr/lib/systemd/system/fstrim.timer

i was able to change:


then I reloaded my systemctl daemon
systemctl daemon-reload

and I think that’s all sorted now.

Cheers for highlighting it, much appcreciated!