17

I have a filesystem that has lots of small files. Currently about 80% of inodes are used (I checked with df -i), however only 60% of disk space is used. How can I 'increase' the number of inodes? If it was just disk space, I know that I could just increase the size of the disk (this disk is on LVM). If I increase the size of the disk, will that make me have more inodes?

I'm willing to grow the filesystem this disk is on, if that'd help.

Amandasaurus
  • 30,211
  • 62
  • 184
  • 246

6 Answers6

17

To answer the original question, even though it is probably late for the questioner - yes, increasing EXT2/3 on LVM2 will also increase the inodes limit.

Just had a partition of 1G size with 65k inodes limit. After

lvextend -L+1G /dev/vg/var
umount /var
resize2fs /dev/vg/var
mount /var

... my inodes limit is now 128k.

Aleš Krajník
  • 2,481
  • 1
  • 15
  • 11
  • 1
    Wow, I was almost desperate, but found your answer and decided to try, and it worked. This should definitely be the accepted answer! Works for LVM as well as for virtual machines :) – vadipp Feb 24 '13 at 16:20
14

man mke2fs

You will see a -N for number of inodes

So you can spec it when you format a new partition. Not so helpful right now, huh?

tune2fs, which tunes the filesystem, doesn't seem to have a way to add more inodes.

But maybe ext3 or 4 does this, and someone else knows....?

So now you have an option: backup, reformat partition, restore.

Paul
  • 1,626
  • 15
  • 19
12

If you were knowing that small files will eat your disk space, you should have used a FS with dynamic inode allocation, like ReiserFS or any new modern FS (XFS, JFS) instead of EXT2/3/4 (which I assume you are using, you not said that).

A filesystem migration is probably a good choice in your situation.

Community
  • 1
  • 2
    If you were knowing that small files will eat your disk space, you should have **done some tuning**. Each filesystem has pros and cons. – Franklin Piat Mar 28 '15 at 07:03
3

As a stopgap, mount a new filesystem, and cp/rm/ln-s some of your fs hierarchy there. Now you have a few spare inodes! You can't mv files between the two fses, so beware breaking things that need to do that, but for many apps this can be transparent.

Then make a new fs, per Paul's advice, and migrate onto that.

Charles Stewart
  • 650
  • 6
  • 19
  • 1
    Of course you can mv files between the two filesystems - a mv is effectively semantic sugar for cp+rm. You can't hardlink between two filesystems. Did you mean something else? – Daniel Lawson Jul 24 '11 at 20:53
  • @Daniel: I mean the rename() system call, and I think it is sloppy practice to use mv as sugar for cp/rm, because of the issue with the semantics around symlinks. I should edit this answer - there's a few places it isn't beautifully clear. – Charles Stewart Jul 25 '11 at 00:30
2

Ext4 suffers the same problem, if you create a small partition and have a ton of small files you will run out of inodes, and if you have flex_bg in features you can't use tune2fs to increase inodes.

Personally I would go with ext4 over any version of rieserfs, just do the following when formatting:

mkfs.ext4 -I 512 /dev/foo
tune2fs -i0 -c0 -o journal_data_writeback /dev/foo

Formatting this way will give you 33160 inodes on a 512M boot partition.

I say this as someone who used reiserfs for years, the kernel support isn't as good as ext*, and the filesystem gets fragmented over time and gets slow.

Anwar
  • 103
  • 4
Suicidal
  • 21
  • 1
-1

Go for resiserfs or any other fs with no inode limitation. Specially regarding to log files, probably you could pack some tons of small unused files into one bigger tar file in order to free a pretty amount of inodes =)

$ find /path -iname "pattern" | xargs tar rvf output_file.tar
adrolmar
  • 1