1

I searched the Internet, but I was not able to find a satisfying answer to my problem. The Problem I'm encountering currently is, that I'm transitioning my data from a NTFS Partition to a ext4 partition. What surprised me was the fact, that I could store less data on the same harddrive with the ext4 filesystem. After investigating a little I found out that this might have something to do with the Inodes of ext4.

me@server:/media$ LANG=C df -i
Filesystem      Inodes IUsed   IFree IUse% Mounted on
/dev/sda1      3815552 31480 3784072    1% /media/storage
/dev/sdb1      1905792  1452 1904340    1% /mnt

When running the command

me@server:~$ sudo find /mnt -type f | wc -l
1431

it tells me that I have 1431 files on the harddrive, each being around 4-8GB. So basically I have too much Inodes for very few files.

My questions are:

  • How can I change the number of Inodes now?
  • Is there maybe a better filesystem for just storing files?
  • You can tune the block size, the inode size, and the size of the journal, but you need to re-format the partition for that. You can see the current values with tune2fs -l <device>. As for a better filesystem for big files: people seem to like Xfs. Historically Xfs used to have various issues though. – lcd047 May 13 '15 at 17:50
2

By default, ext2/ext3/ext4 filesystems have 5% of the space reserved for the root user. This makes sense for the root filesystem in a typical configuration: it means that the system won't grind to a halt if a user fills up the disk, critical functionality will still work and in particular logs can still be written. It doesn't make sense in most other scenarios.

To avoid reserving 5% for the root user, pass -m 0 to mkfs when creating the filesystem, or call tune2fs with the option -m 0 afterwards.

Though if your filesystem is 95% full, you should look into expanding it. Most filesystems (including both NFS and the ext? family) don't operate efficiently when they're very nearly full.

  • This was exactly what I was looking for! Also I did some calculations on howmuch space the Inodes consume. (256 bytes * 1905792 / 1024^2) = 465,28 MegaByte. So it is really not worth reducing the Inodes, but the reserved space! – Benjamin May 14 '15 at 11:58
2

Under most typical use cases, most filesystems created with default settings will have way more inodes than they will ever need. But that's actually a pretty good tradeoff considering:

  • The inode table doesn't really waste all that much space, all in all. It's almost never worth reducing the number of inodes just to squeeze the last few bytes of available space out of a filesystem.
  • If the number of inodes is reduced and then, later on, the filesystem runs out of inodes while it still has plenty of blocks free, it is very frustrating to be unable to use all those free blocks, and you cannot easily fix the problem because you cannot change the number of inodes after a filesystem has been created.

Is there maybe a better filesystem for just storing files?

Not really. ext4 is fine.

Every filesystem will store files a little bit differently and therefore have storage overhead that's a little bit different, but the difference should be minor: a few percent difference in the most extreme cases.

You could try xfs. I seem to have noticed in the past that on some filesystems I had with millions of files each about 250KB in size, xfs did very slightly better on space efficiency. But YMMV because your use case is different.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.