Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I had a problem (new to me) last week. I have a ext4 (Fedora 15) filesystem. The application that runs on the server suddenly stopped. I couldn't find the problem at first look.

df showed 50% available space. After searching for about an hour I saw a forum post where the guy used df -i. The option looks for inodes usage. The system was out of inodes, a simple problem that I didn't realize. The partition had only 3.2M inodes.

Now, my questions are: Can I make the system have more inodes? Should/can it be set when formatting the disk? With the 3.2M inodes, how many files could I have?

share|improve this question
Every file or directory uses one inode. A hard link to a file does not create an inode. en.wikipedia.org/wiki/Inode – Paul Tomblin Dec 12 '11 at 1:59
up vote 18 down vote accepted

It seems that you have a lot more files than normal expectation.

I don't know whether there is a solution to change the inode table size dynamically. I'm afraid that you need to back-up your data, and create new filesystem, and restore your data.

To create new filesystem with such a huge inode table, you need to use '-N' option of mke2fs(8).

I'd recommend to use '-n' option first (which does not create the fs, but display the use-ful information) so that you could get the estimated number of inodes. Then if you need to, use '-N' to create your filesystem with a specific inode numbers.

share|improve this answer
You can use mke2fs -i to specify the number of inodes. Its documentation indicates that “it is not possible to expand the number of inodes on a filesystem after it is created”. – Gilles Dec 12 '11 at 0:35
Can't change the number of inodes, but we can change the size (which is quite useless) tune2fs. Your answers were helpful, but the question now is what's the relation between inodes and total number of files? – piovisqui Dec 12 '11 at 1:35
@piovisqui: each file consume on inode, which is a pointer in the filesystem. if the file is an hard-link to another file it has the same inode. – Hanan N. Dec 12 '11 at 4:47
@Gilles The -i options specifies the size of the inode, not how many there are. The -N option sets the number inodes. – theillien Oct 23 '14 at 20:12
The relation between inodes and file numbers isn't necessarily 1:1. The first inode contains a list of pointers to blocks where the file is stored. If the list of blocks can't fit within one inode, then the inode contains a list of pointers to inodes which list the blocks where the file is stored. If it doesn't fit there then it goes 3 sets of inodes deep for that list of blocks etc. – StuWhitby Apr 14 '15 at 14:02

With 3.2 million inodes, you can have 3.2 million files and directories, total (but multiple hardlinks to a file only use one inode).

Yes, it can be set when creating a filesystem on the partition. The options -T usage-type, -N number-of-inodes, or -i bytes-per-inode can all set the number of inodes. I generally use -i, after comparing the output of du -s and find | wc -l for a similar collection of files and allowing for some slack.

No, it can't be changed in-place on an existing filesystem. However:

  • If you're running LVM or the filesystem is on a SAN's LUN (either directly on the LUN, or as the last partition on the LUN), or you have empty space on the disk after the partition, you can grow the partition and then use resize2fs to expand the filesystem. This adds more inodes in proportion to the added space, roughly. If you want to avoid running out of inodes before space assuming that future files on average have about the same size, set a high enough reserved block percentage using tune2fs -m.
  • If you have enough space and can take the filesystem offline, then take it offline, create a new filesystem with more inodes, and copy all the files over.
  • If just a subset of the files are using a lot of the inodes and you have enough free space, create a filesystem on a loop device backed by a file on the filesystem, create a filesystem with more inodes (and maybe smaller blocks as well) on it, and move the offending directories into it. That's probably a performance hit and a maintenance hassle, but it is an alternative.
  • And of course, if you can delete a lot of unneeded files, that should help too.
share|improve this answer

As another workaround I could suggest considering packing huge collections of files into an uncompressed(!) tar archive, and then using archivemount to mount it as a filesystem. A tar archive is better for sharing than a filesystem image and provides similar performance when backing up to a cloud or another storage.

If the collection is supposed to be read-only, squashfs may be an option, but it requires certain options enabled in the kernel, and xz compression is available for tar as well with the same performance.

share|improve this answer
Nice suggestion. – piovisqui Nov 30 '15 at 17:38

I have an alternate solutions for this situation. Lets say you have 1000 inodes in a partition of 10G. But due to inodes limit you are not suppose to use all space of partition. But in this solutions you will be able to use the remaining space of the partition without formatting it.

$ df -i  # see list ( I need just one free inode here so move just one file into other PARTITION)
/dev/part1  1000 999 1 99.9%     /data

$ dd if=/dev/zero of=/data/new_data
$ mkfs.ext4 /data/new_data
$ mkdir /data1
$ mount /data/new_data /data1

for permanent mounting

$ echo "/data/new_data /data1 ext4 defaults 0 1" >> /etc/fstab
share|improve this answer
Welcome to U&L. I took the liberty to reformat your answer to the more usual representation of code here, inserting a prompt ($) to clearly distinguishing between commands and output (if they were only command, the prompt is normally left out). I also changed the SHOUTING in the bold phase emphasis, which is what I think you intended. You can roll back the changes if I misrepresented things – Anthon May 25 '15 at 5:26
I think this solution has logic, but you need to manage the size when running dd. – piovisqui May 26 '15 at 14:51
The details are wrong, you'd need to use a loop device, and maybe even unionfs depending on the application, but this is the only solution avoiding formatting and restoring from backup which is no fun when in a hurry with millions of files. There are circumstances where this could save the day ! – medoc Jul 29 '15 at 20:43

Recently ran into this issue when using apt or aptitude upgrade.

df -h

Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1      7.8G  5.1G  2.3G  70% /

df -i

Filesystem     Inodes  IUsed  IFree IUse% Mounted on
/dev/xvda1     524288 521497   2791  100% /

Issued command:

du /|sort -k1 -n

Revealed most of files were in subfolders for several kernel versions within:


Removed those subfolders and inode problem was fixed.

df -i

Filesystem     Inodes  IUsed  IFree IUse% Mounted on
/dev/xvda1     524288 104986 419302   21% /
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.