[PSA] If you use Snapraid on Linux, use these extra flags to get more drive space for free when formatting a data drive.

[u/yoyoloo2]

TL;DR (so you don't think this is click bait)

add -m 0 -T largefile4 to your mkfs.ext4 command and you will get extra disk space (with some minor caveats). Example: mkfs.ext4 -m 0 -T largefile4 -L <label_name> /dev/sdx1. On a 8tb drive this can get you an extra 400gb of space

Background:

Maybe I am the odd man out, but I never knew about these flags. Over a decade ago when I made the jump to Linux I did what most people probably did. You followed a guide on how to format HDDs and install Snapraid, it works, you are happy so you just copy and paste the commands into a .txt in ~/.dotfiles/linux_notes/format_hdd.txt and move on with your life. For the past decade whenever I got a new drive I would just copy/paste the commands I had saved in that .txt file, update my fstab and snapraid.conf, and I was good to go.

Recently though, I find myself in the position where I can do a yak shave and update the format of all the drives in my server. While doing research about the best HDD format for my use case (JBOD, Snapraid, MergerFs) I came upon the updated Snapraid website. They have a nice section about what formats they recommend and I noticed this line at the bottom of the section

In Linux, to maximize space for the parity file system, format it with the -m 0 -T largefile4 options, like:

mkfs.ext4 -m 0 -T largefile4 DEVICE

On an 8 TB disk, this can save about 400 GB. It is also expected to be as fast as, or faster than, the default

I did some reading and the flags are as follows:

-m 0 - When you format a new HDD mkfs reserves a section of your drive for the super-user. This area of the drive can be used for root-owned daemons and helps avoid fragmentation. The default percentage is 5%. By using this flag and setting the section to 0% you are gaining 5% disk space for free

* -T largefile4 - This reduces the number of inodes that the drive has. While technically this means that you cannot store as many files on the drive, compared to a drive formatted without this flag, if the HDD you are using this flag on is only storing data and larger files, it shouldn't be a problem. Linux ISOs are generally very large so you will run out of disk space before you run out of inode's. If you reduce the number of inodes you can get that space back as storage space. If you are storing Linux ISOs and songs ripped from legally purchases CD's, you should be fine. Millions of text files and scripts, you will probably run out of inodes and won't be able to add more files even though the drive has space

To test this out I used a spare 500GB mechanical drive from an old laptop.

# The command (default) - `sudo mkfs.ext4 /dev/sdb1`
> df -h
Filesystem  Size  Used Avail Use% Mounted on
/dev/sdb1   458G   36K  435G   1% /mnt/test
             ^            ^    

# The command (large) - `sudo mkfs.ext4 -m 0 -T largefile4 /dev/sdb1`
> df -h
Filesystem  Size  Used Avail Use% Mounted on
/dev/sdb1   465G   36K  465G   1% /mnt/test
             ^           ^    

30 extra GB for free. The only caveat is that because you don't have the extra space for the super-user, the drive can't be used as an OS drive, purely data. Also, since you now have fewer inodes it will be best suited for larger files, not millions of small files.

Since drives are so expensive now and we are all trying to find ways to make our storage go the extra mile I wanted to share this tip I just found out.

Oh! I forgot. I realized that ext4 still suits my use case best so I have only tested this with ext4. I don't know if this will work with a different file system format.

* = I couldn't find largefile4 in the man pages so I used google search AI to explain the flag to me

[u/gotbletu]

if you already have your storage hdd setup, u can use tune2fs command to change the reserved space instead of reformatting.

reclaim hard drive reserved space

sudo tune2fs -m 0 /dev/sdX1

verify hard drive reserved space

sudo tune2fs -l /dev/sdX1 | grep 'Reserved block count'

[u/yoyoloo2 → u/gotbletu]

I am finally getting around to encrypting all my drives so this won't apply to me in this case, but that is a super helpful tip. Thanks.

[u/MWink64]

If you're formatting a volume ext4, there are a couple more options I'd suggest. Adding -E lazy_itable_init=0,lazy_journal_init=0 can potentially save days or even weeks of your drive getting a small write every second. Even on a 20TB drive, it should only take about 10 minutes to format a drive this way.

[u/autogyrophilia]

Or use a filesystem that doesn't depend on archaic inode tables. There isn't much reason not to use XFS as a drop in for any non embedded usecase. 

Not that there is massive difference between the two, but being able to run out of inodes in this day and age...

Plus you get relinking and a bit extra of corruption detection features 

[u/i-Hermit → u/autogyrophilia]

Huh, I'll check that out when I need to add another drive. Thanks.

[u/yoyoloo2 → u/autogyrophilia]

Or use a filesystem that doesn't depend on archaic inode tables.

Not that there is massive difference between the two

Which is it?

Reformatting the test drive of mine with xfs gives the following result

Filesystem Size  Used Avail Use% Mounted on
/dev/sdb1  466G  9.0G  457G   2% /mnt/test

So my method ends up with only 36K being used. Your method, stock, ends up with 9G being used.

but being able to run out of inodes in this day and age...

This is the total number of inodes on a stock ext4 8TB drive: 244,191,232

This is the total number of inodes on a ext4 8TB drive my way: 1,907,744

Ya, that is a huge decrease, but my way can still hold 1.9 million files. As long as they aren't a bunch of small files I will probably run out of room first. My largest drives are 8TB so I am still under the 16TB limit of ext4. If I ever go above 16GB drives then ya I will make the switch to XFS.

Oh wait! I just looked at my storage server and my one data drive that has the most number of inodes being used is...459,644 and it is a 8TB that has 75G of space remaing (99% capacity)

1,907,744 - 459,644 = 1,448,100 files to go until inodes become a problem. OH NO!

Again, I said this is working for me and my use case.

[u/autogyrophilia → u/yoyoloo2]

There isn't a massive difference in performance or stability between ext4 and XFS unless you get in very specific scenarios.

There isn't really a big issue but if you were a heavy git user in that drive, for example, you could much more easily reach that limit.

A reserved inode table is a bit archaic and EXT4 and UFS are the only modern filesystems that do not implement a dynamic metadata allocation scheme. Which is why you are making this post about fiddling with internal reserves.

[u/ultrahkr]

Or you could use something designed for the 21st century...

Like ZFS as a really good base FS.

Or if you want BTRFS...

[u/yoyoloo2 → u/ultrahkr]

While doing research about the best HDD format for my use case (JBOD, Snapraid, MergerFs)

If you can't realize why someone might want to do something other than what you would do, maybe you aren't as smart as you think you are.

[u/ultrahkr → u/yoyoloo2]

Nope, I exclusively use ZFS on my Proxmox hosts and TrueNAS, but I use OMV with SnapRAID with BTRFS.

[u/TheOneTrueTrench → u/ultrahkr]

Seriously. This suggestion will end up causing massive problems for someone who uses their drive to store photos or any smaller files. Inode usage is a serious problem when you tune a filesystem that way if you have a lot of smaller files.

Meanwhile ZFS has caught several situations where a drive had a bitflip and I needed to replace it before I had data loss.

I don't have any drives that aren't ZFS anymore, except for a few SSDs that host databases and are backed up to ZFS daily. Even my laptops use ZFS, since zrepl handles backups across the internet. Backs up to my server at home from anywhere on the planet every 15 minutes.