[Lustre-discuss] [wc-discuss] Bad reporting inodes free

[Dilger, Andreas]

On 2012-09-28, at 2:15, Johann Lombardi <johann.lombardi at linux.intel.com> wrote:

> On 28 sept. 2012, at 09:03, Alfonso Pardo wrote:
>> If I am need more inodes in my OST, I have a big trouble!, becouse I will need format all OST in my production storage environment.
>> 
>> Any ideas to increase the inodes number in my OST without formating?
> 
> The number of inodes is decided at mkfs time and can't be changed easily. If your OSTs are on lvm, one option could be to increase the size of the logical volumes and resize the backend ldiskfs filesystems. However, i'm not sure someone has ever tried this with ldiskfs/lustre, so i would not do this on a production filesystem w/o some testing first.

Right. It would be possible to use "lfs_migrate" to empty an OST, then reformat with more inodes, then migrate another OST's files to the newly formatted OST, repeat. However, I think that would be pointless, see below. 

> In any case, i think the issue here is that you seem to have a default stripe count of -1. That's why you are limited by the number of inodes available on one single OST. You should still be able to create ~1.250M x 18 = 22.5M 1-stripe files.

That is my thought as well - the default file striping is too large. What is the average file size (total space used / mdt used inode count)?  Having many stripes on small files (below tens of MB per stripe) is actuall bad for performance.

If this is the case (many stripes on small files) then it is possible to use lfs_migrate to change the striping of the files incrementally (caveat that it is only safe for files known not to be in use). 

As Johann mentioned, there are still over 20M OST inodes free, and if the existing files were converted to 1-stripe files there would be about 330M OST inodes free.

Cheers, Andreas