[Lustre-discuss] How to change inode capacity

[Brian J. Murrell]

On Fri, 2009-01-30 at 11:58 +0900, Satoshi Isono wrote:
> Hi Brian,

Hi.

> Current Lustre version is NOT able to multiple MDT. Is it right?

This is correct.

>  I found the article in Lustre FAQ.
> 
> http://wiki.lustre.org/index.php?title=Lustre_FAQ
>    * What is the maximum number of files in a single file system? In a
> single directory? 
> 
> So, if we use current Lustre 1.6.x on EXT3, we can only support single
> MDT. Then, according to the limitation of the number of inodes, we are
> able to use inodes up to 4 billion.

Hrm.  To get 4 billion inodes out an 8TB device (8TB is the current
limit on the size of a Lustre target) you'd need to be using 2k blocks:

8*1024^4/(4*1024^3)
2048

The default is 4k blocks (so that means in order to use 2k blocks you
will need to specify that in your MDT format command -- man mkfs.lustre
and man mkfs.ext3) which would yield only 2 billion inodes out of the
maximum 8TB Lustre device.  A 2k block size is certainly usable as long
as you didn't want to too-widely-stripe files.

Providing for the maximum striping of 160 stripes is why we allocate 4k
blocks.  It takes a 4k inode to hold the striping info for 160 stripes.

> This means that a Lustre consisted on EXT3 can support 4 million
> files.

4 _b_illion files, not 4 million and as long as you can utilize 2k
inodes, yes.

> Another question to you, When changing #inodes into maximum number,
> are there any demerit/un-merit points?

Reducing the block size to 2k does have some performance issues.

> I want to know the tradeoff changing #inodes. In my site, the total
> OST capacity is 800TB and size of MDT is 123207680 (123 million). What
> do you think about the number of inodes which I will change?

That is so completely subjective to what you are storing in the
filesystem.  I could not even try to make a comment.

> I understand. Of course, I am going to choose more safety way to
> change #inodes.

FWIW, one of our engineers reports having used resize2fs (offline) on a
lustre device successfully in the past.  It's still a completely
unsupported operation however and you must proceed on that path with all
caution should you choose it.

b.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.lustre.org/pipermail/lustre-discuss-lustre.org/attachments/20090130/7e711448/attachment.pgp>