Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I am currently using backintime to take "snapshots" of my file system. It is similar to rsnapshot in that it, makes hard links to unchanged files. I have recently run out of inodes on my EXT4 filesystem. df -hi reveals I have used 9.4 million inodes. A rough count of the number of current directories times the number of snapshots plus the number of current files suggests that I may in fact be using 9.4 million inodes.

From what I understand the EXT4 filesystem can support around 2^32 inodes. I am considering reformatting the partition to use all 4 billion or so inodes, but I am concerned that this is a bad idea. What are the drawbacks of having so many inodes in an EXT4 filesystem? Is there a better choice of filesystem for an application like this?

share|improve this question
Note that hard links do not use up inodes, so this is probably not backintime's fault. –  Jakob Nov 23 '14 at 19:32

2 Answers 2

up vote 3 down vote accepted

That is a really bad idea. Every inode consumes 256 bytes (may be configured as 128). Thus just the inodes would consume 1TiB of space.

Other file systems like btrfs can create inodes dynamically. Use one of them instead.

share|improve this answer
I am a little reluctant to use btrfs for my backups since it is still technically unstable. Is btrfs substantially better than reiserfs or xfs for this type of usage? –  StrongBad May 2 '13 at 15:38
btrfs supports snapshots on file system level. Except for that I cannot compare it to reiserfs and xfs (am not even sure about xfs and snapshots). I am not using btrfs yet but my impression is that it is not considered unstable any more. –  Hauke Laging May 2 '13 at 16:06
I'm more than reluctant to use brtfs, it's still not a solid performer. Yes it's improved, but ext4 is still my preference. –  TechZilla May 19 '13 at 23:53

I really can't stress this enough, don't create a boatload of inodes!

First your fsck runtime can be lengthened exponentially, although some of those concerns were addressed in ext4. More importantly, inodes aren't the only limiting file number factor, it's likely impossible to use all those inodes. This isn't just practically speaking, it may actually be technically impossible.

An excerpt from the mkfs man page,

-i bytes-per-inode Specify the bytes/inode ratio. mke2fs creates an inode for every bytes-per-inode bytes of space on the disk. The larger the bytes-per-inode ratio, the fewer inodes will be created. This value generally shouldn't be smaller than the blocksize of the filesystem, since in that case more inodes would be made than can ever be used. Be warned that it is not possible to expand the number of inodes on a filesystem after it is created, so be careful deciding the correct value for this parameter.

When creating your new filesystem, realistically speaking, you should try setting your bytes-per-inode to your blocksize. Technically this is just a guideline, and it's by nature a generalization, but it's a good starting point.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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