I have just converted an NTFS partition to ext4, however the total space seems reduced from 421G to 415G. Where did the 6G go? And, the reserved space is grown to 199M in ext4, much larger compared to 78M in NTFS, why?

The partition is mainly used for movies/musics, so most files are very large (>10M each). I want to use ext4 file system, is there any suggestion?

    /dev/sdb4             421G   78M  421G   1% /mnt/mmedia

    /dev/sdb4             415G  199M  393G   1% /mnt/mmedia
                       (415G - 199M == 393G ?)

It's also weird that the remaining size of ext4 is 393G, shouldn't it be 415G or 414G? What happened to the disappeared 22G? Compared to NTFS, ext4 consumed 6.6% of total space, that's really a big deal.

The question is:

  1. What is 6G mainly used for, for journal, for redundancy, or for indexing?
  2. Why the remaining space 393G not 415G? There is a 22G hole which is rather big.
  3. What parameters would you advice if this ext4 partition is used to store movie/music files? It's said ext4 performs better then ext3 for large partitions, is it true? I won't back to ext2 which isn't journal.

5 Answers 5


What is 6G mainly used for, for journal, for redundancy, or for indexing?

(Not known yet.)

Why the remaining space 393G not 415G? There is a 22G hole which is rather big.

It's 5% reserved blocks for superuser, which is used to avoid fragmentation. You can adjust it to 1% by mkfs.ext4 -m 1.

What parameters would you advice if this ext4 partition is used to store movie/music files?

You can specify a usage option to mkfs.ext4, e.g., mkfs.ext4 -T large_file, this will let mkfs.ext4 to decide parameters for partitions containing large files.

  • 1
    the 6G will be for the inode lists.
    – Sirex
    Jan 10, 2012 at 7:57
  • 1
    Reserved blocks also limit the impact of a Denial Of Service attack where regular users fill up a disk to the point where log files cannot be written anymore. The reserved space will at the very least give root sufficient logs to catch the offending user.
    – MSalters
    Jan 10, 2012 at 10:28
  • My /etc/mke2fs.conf speaks of "largefile" and "largefile4" parameters for -T, not "large_file". Apr 18, 2013 at 6:33
  1. The 6GB is inodes. ext4 defaults to 1/64 (1.56%) for inodes, each 256B; so can fill with 16KB files
  2. The df available space excludes space reserved for root, 5% by default, use tune2fs -m
  3. mkfs.ext4 -m 0 -N 4000000 /dev/whatever # reformats, 0 reserved, 4 million inodes uses 1GB
  4. ext4 fsck is much quicker than ext3; apart from that you won't notice any difference

Each file / dir needs 1 inode. You can't change the number of inodes after creating an ext filesystem. Even 1000000 inodes would be plenty for that partition, if you will use it only for movies and music.

The NTFS Master File Table (MFT) is slightly more flexible, so NTFS can cram in more data by default.

The only good reason to use NTFS on Linux is to share files with Windows. It will work okay for media, but lacks various UNIX features, so is not suitable for general purpose on Linux. Don't compile on it!

  • Each inode 256B, so can fill with 16KB files Do you mean there is 16K-256 = 16128 free bytes in each inode?
    – Lenik
    Jun 9, 2012 at 2:10
  • 1
    I mean if you use 1/64 of a device for inodes tables, and each inode is 256B, then you get one inode per 16KB of device... actually it's 1 inode per 15.75KB of the remaining device, but close enough. So you have enough inodes to fill up the whole disk with 16KB files. If you anticipate having much larger files, e.g. videos, you can make do with fewer inodes and save perhaps a few GB from the device. Jun 13, 2012 at 11:25

Yeah, this is a neat little topic. Each file system implements its datastructures differently. Something neat you can try is formatting a partition with various file systems and comparing. The "free" space will differ. Also, as you fill them up, the will be a difference in storage overhead and so in a sense how much space is required to store the same file CAN differ depending on the file system. Usually, when you format a file system you can also select some parameters for how it's to be arranged - this has an impact too.

The answer to your question is one of those "it depends" answers. I think, over all, 6/400 GB isn't a terrible variance, but indeed, that is noticeable. Still storage space is getting cheaper and cheaper. But I think file systems are probably getting heavier as we want more fancy features in them. I suspect ext2 is a fair bit leaner than ext4. I'd be interested to see some real-world numbers on that. Of course, that "efficiency" comes at a price (biggest one being that it's not journaled and thus faster AND more easily corrupted).

As for why ext4 takes more space in this case, I'll assume your storage custers on NTFS were set to address your storage space is much bigger blocks than your ext4 parameters called for. If this is true, then you should get more efficient storage use if you have a lot of relatively small files.

Suffice to say, the whole subject matter goes on and on. If you want more info, I'd suggest to take a look at various wikipedia pages comparing the file systems out there.. As well as look at man pages for each FS you're interested in.

Hope you find that helpful.


Reserved super-blocks is one thing but not at all the amount you are referring to. Changing the reserved super-blocks doesn't show in "total available space'.. that doesn't change. It is the number of inodes x their size. On ext4 by default, expect something like 256 bytes per inode and for 400 GB, I am guessing mkfs.ext4 will do ~ 25-30 mill perhaps. Use dumpe2fs -h to see the actually number. This makes up the 6 GB you are missing and not the reserved blocks someone is on about.

(Eg. inode-count x inode-size b / 10243 ) GBs.

The df -h output I suspect could be to do with some lameness ;p Try doing it again and specify half your i-nodes (You can safely do it , and even more if you are bold) but be aware that lots of directories could make you run out of inodes before space.

Eg. ext4 reserves several (93-4?) inodes per directory , assuming you intend to hold more than just one or two files, and thus making it more efficient. If you though, have 1 million folders with 1 million files in them, you will run out of inodes on that layout waaay before you actually run out of space. Usually inodes are only used within a few percent of space, but can spike to 35% so divide by two is fairly safe for desktop users but don't do more to be on the safe side.

Here is an example:

415 GB RAW (dev/sdb1 say)
mkfs.ext4 -m0 -Ndefault#/2 -Lext4-1 -O extent,dir_index,large_file,sparse_super,uninit_bg /dev/sdb1

the options will help for large files/partitions with media say. uninit_bg is for recent kernels.

This is posted even if it's oldish for future readers.


I had a (full) ntfs filesystem containg about 1000 GB of data with only a few hundred megabytes free. Even if ext4's formatted capacity was far less than ntfs I remember that when I copied everything over I still had about 70GB free on ext4 even if the formatted capacity was less. (Remember the ntfs was full). I can't promise that this happen to you but at least for the files I had ext4 was a real space saver tough! :)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .