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.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Lustre-discuss mailing list [email protected] http://lists.lustre.org/mailman/listinfo/lustre-discuss
