![](https://seccdn.libravatar.org/avatar/401407fee6c7ce419be6fdf1feff4940.jpg?s=120&d=mm&r=g)
Hi all, I'm running out of inodes on one of my partitions (IUsed in df -i = 100%). It's my understanding that this limit can be increased only when you format the partition (at least on ext2/3). If I recreate the partition with a higher inode limit, do I also need to increase /proc/sys/fs/file-max and /proc/sys/fs/inode-nr? Should it be the case, is it still true that inodes limit should be 3/4 times the file-max limit? Because on that 9.3 server, they are the same. Kind regards, Gaël
![](https://seccdn.libravatar.org/avatar/99bbf0e2807d0c1a81e021665cc9e09f.jpg?s=120&d=mm&r=g)
On Monday 25 September 2006 14:15, Gaël Lams wrote:
I'm running out of inodes on one of my partitions (IUsed in df -i = 100%).
It's my understanding that this limit can be increased only when you format the partition (at least on ext2/3).
That's correct. The number of inodes is calculated automatically at format-time based off of the number of bytes/inode you specify when formatting (or the default size, of course). For example, mkfs.ext2 uses the [-i bytes-per-inode] option and allows you to specify the number of inodes with -N (but i've never seen -N actually used). To change the number of inodes, you need to reformat. (We won't consider LVM-like options here, since that apparently doesn't apply to you.)
If I recreate the partition with a higher inode limit, do I also need to increase /proc/sys/fs/file-max and /proc/sys/fs/inode-nr?
You shouldn't have to touch the /proc/sys files. Those are generated by the kernel and its drivers. Any changes you make will be lost at reboot, anyway, because /proc is an in-memory filesystem.
Should it be the case, is it still true that inodes limit should be 3/4 times the file-max limit? Because on that 9.3 server, they are the same.
The number of inodes is calculated automatically, as mentioned above. -- ----- stephan@s11n.net http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts
![](https://seccdn.libravatar.org/avatar/401407fee6c7ce419be6fdf1feff4940.jpg?s=120&d=mm&r=g)
It's my understanding that this limit can be increased only when you format the partition (at least on ext2/3).
That's correct. The number of inodes is calculated automatically at format-time based off of the number of bytes/inode you specify when formatting (or the default size, of course). For example, mkfs.ext2 uses the [-i bytes-per-inode] option and allows you to specify the number of inodes with -N (but i've never seen -N actually used).
hmm, now it's clear to me. As I have some spare space, when I recreate the partition I will just make it bigger and let the bytes-per-inode default
To change the number of inodes, you need to reformat. (We won't consider LVM-like options here, since that apparently doesn't apply to you.)
you're right, it doesn't apply
You shouldn't have to touch the /proc/sys files. Those are generated by the kernel and its drivers. Any changes you make will be lost at reboot, anyway, because /proc is an in-memory filesystem.
I think that those numbers can be changed in sysctl.conf to change them permanently but I was wondering whether these numbers were some kind of hard limit (i.e I thought that you could have more inodes on one partition but it should be no more than the limit I saw in /proc ). From your answer I understand that it's not the case Kind of curiosity: do you know how these numbers are estimated? Because I had a look on both a virtual machine and physical machines, both with SuSE 9.3 (i.e same kernel) and the numbers (file-max and inode-nr) are really differents. Thank you for the answer, Kind regards, Gaël
![](https://seccdn.libravatar.org/avatar/99bbf0e2807d0c1a81e021665cc9e09f.jpg?s=120&d=mm&r=g)
On Monday 25 September 2006 15:40, Gaël Lams wrote:
I think that those numbers can be changed in sysctl.conf to change them permanently but I was wondering whether these numbers were some kind of hard limit (i.e I thought that you could have more inodes on one partition but it should be no more than the limit I saw in /proc ). From your answer I understand that it's not the case
i wasn't aware of sysctl.conf, to be honest. It may be i who is misunderstanding, and not you.
Kind of curiosity: do you know how these numbers are estimated? Because I had a look on both a virtual machine and physical machines, both with SuSE 9.3 (i.e same kernel) and the numbers (file-max and inode-nr) are really differents.
As an abstract example: let's say we have 1000 blocks of space, and we allocate 1 inode/block. We will then have a max of 1000 inodes (1000/1). If we allocate 4 blocks/inode, we then have a limit of 250 (1000/4) inodes. Each file inode can point to, at most, one file, so we would have a hard limit of 250 files in that case. When formatting a partition there are tradeoffs to be made in selecting the block sizes. If you know you'll need lots of small files, select a small bytes/inode ratio (e.g., 1k-4k/inode). OTOH, if you know you're only going to store lots of large files, selecting a large ratio, e.g. 32k/inode, can be more performant. However, on such a system you would use 32k of space even for files which are 1 byte in size. On today's drives, this normally poses little problem, though. -- ----- stephan@s11n.net http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts
![](https://seccdn.libravatar.org/avatar/814f1c9f82898e057fe8d46a106381fd.jpg?s=120&d=mm&r=g)
When formatting a partition there are tradeoffs to be made in selecting the block sizes. If you know you'll need lots of small files, select a small bytes/inode ratio (e.g., 1k-4k/inode). OTOH, if you know you're only going to store lots of large files, selecting a large ratio, e.g. 32k/inode, can be more performant. However, on such a system you would use 32k of space even for files which are 1 byte in size. On today's drives, this normally poses little problem, though.
Reiserfs makes the impression it would be inodeless (as in counting), by showing 0 on `df -i`, and the 'tail packing' thing just emphasizes that. Jan Engelhardt --
![](https://seccdn.libravatar.org/avatar/99bbf0e2807d0c1a81e021665cc9e09f.jpg?s=120&d=mm&r=g)
On Monday 25 September 2006 21:09, Jan Engelhardt wrote:
When formatting a partition there are tradeoffs to be made in selecting the block sizes. If you know you'll need lots of small files, select a small bytes/inode ratio (e.g., 1k-4k/inode). OTOH, if you know you're only going to store lots of large files, selecting a large ratio, e.g. 32k/inode, can be more performant. However, on such a system you would use 32k of space even for files which are 1 byte in size. On today's drives, this normally poses little problem, though.
Reiserfs makes the impression it would be inodeless (as in counting), by showing 0 on `df -i`, and the 'tail packing' thing just emphasizes that.
That's true - i didn't think about reiser when i wrote that. reiser can pack multiple small files into a single data block, which kind of warps (or eliminates?) the whole idea of inodes. -- ----- stephan@s11n.net http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts
![](https://seccdn.libravatar.org/avatar/814f1c9f82898e057fe8d46a106381fd.jpg?s=120&d=mm&r=g)
I'm running out of inodes on one of my partitions (IUsed in df -i = 100%).
It's my understanding that this limit can be increased only when you format the partition (at least on ext2/3).
Out of curiosity, how many inodes can your filesystem hold? (df -i under INodes) Jan Engelhardt --
![](https://seccdn.libravatar.org/avatar/401407fee6c7ce419be6fdf1feff4940.jpg?s=120&d=mm&r=g)
Out of curiosity, how many inodes can your filesystem hold? (df -i under INodes)
+/- 396 000 inodes for a 3 Gbs partition. I will move it to a 10 Gbs partition which will give more or less 1 150 000 possible inodes. I should be safe for a while :-) Gaël
![](https://seccdn.libravatar.org/avatar/814f1c9f82898e057fe8d46a106381fd.jpg?s=120&d=mm&r=g)
+/- 396 000 inodes for a 3 Gbs partition. I will move it to a 10 Gbs partition which will give more or less 1 150 000 possible inodes. I should be safe for a while :-)
396k inodes is not much. Just 9 ±1 kernel tree. Here you see a developer of all sorts vv :-) Filesystem Inodes IUsed IFree IUse% Mounted on /dev/hda8 40886656 410436 40476220 2% / Filesystem 1K-blocks Used Available Use% Mounted on /dev/hda8 40866692 11015316 29851376 27% / Jan Engelhardt --
participants (3)
-
Gaël Lams
-
Jan Engelhardt
-
stephan beal