9

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?

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

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.

Improve this answer
5
  • 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
  • 1
    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. – J. M. Becker May 19 '13 at 23:53
  • @HaukeLaging How do you know the exact size of each inode? Thanks – Bionix1441 Feb 21 '18 at 7:42
  • 1
    @Bionix1441 All inodes have the same size: dumpe2fs -h /dev/whatever | grep 'Inode size' – Hauke Laging Feb 22 '18 at 13:30
3

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 the OPs new file system, realistically speaking, the OP should start to figure numbers to the maximum of bytes-per-inode = blocksize.... for everyone who reads this later, the OP has a very unusual case where he has a HUGE number files.

Improve this answer
4
  • 1
    But if you have a small blocksize then setting bytes-per-inode to blocksize will create a lot of inodes right? Regarding the warning in your fist sentence - what are the risks? Just fsck performance? – UpTheCreek Mar 17 '15 at 7:26
  • +1'd you, yes it would create lots of inodes, which IMO is stupid, but it was directed at the OP... so I wanted to provide a theoretical maximum that at least could potentially be used... since he was so off the deepend, he would have more than he could even use in theory. It was my ... dont ever go smaller than blocksize=Bytes per inode, no matter what. – J. M. Becker Mar 20 '15 at 16:04
  • O and yea, for most filesystems, like DB's and whatnot, I have large files never more than say a few thousand. So I like using -Tlargefile4, or even Tlargefile for good amount more inodes. Too many inodes has a deep cost for sure, they take up space themselves, and believe me that fsck performance is dead serious. We're talking practically exponential slowdowns, like 30 seconds vs 2 days... and this is I/O bound. Not to mention slow downs of file listing, indexing... etc. no matter how good ext4 was, more inodes is more to index, even though it does it much better than ext2/3. – J. M. Becker Mar 20 '15 at 16:13
  • So don't be too scared, I just wanted to counter the OP's idea that this was somehow cost free.. EVERYTHING has it's cost, so always weigh the pros and cons. For most the default amount is a totally acceptable amount, especially for an OS drive...and the performance impact is generally minimal either way... but that assumes you're not at insane loads of inodes type numbers. – J. M. Becker Mar 20 '15 at 16:16

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.