[Lustre-devel] F/S stats visualisation

Andreas Dilger adilger at whamcloud.com
Mon May 2 13:00:51 PDT 2011

In fact in the patch I recently posted to LU-255 mkfs.lustre is a bit smarter about how many inodes are allocated on the MDT, based on the default striping count given by --stripe-count-hint. It is more aggressive about allocating inodes on the MDS, because we waste a lot of space otherwise. 

That is not in itself harmful with HDDs because there is too much space anyway and you need more drives to have enough IOPS, but space on SSDs is much more precious. 

Cheers, Andreas

On 2011-05-02, at 10:32 AM, Johann Lombardi <johann at whamcloud.com> wrote:

> On Mon, May 02, 2011 at 05:51:36PM +0200, rf at q-leap.de wrote:
>> It seems lfs df -i is indeed buggy showing totally bogus numbers
>> (see https://bugzilla.lustre.org/show_bug.cgi?id=24489)
> In this case, you run df on the server directly, so you are comparing statfs information as returned by ext4/ldiskfs with what you get through lustre (i.e. lfs df or df on a lustre client).
> Lustre takes for granted that 1 EA block is needed for each inode (conservative approach) and adjusts the total number of inodes accordingly (see fsfilt_ext3_statfs()).
> That being said, with large inode support and mkfs.lustre adapting the inode size based on the default stripe count, i am not sure this "adjustment" makes sense any more. We could instead print a warning at mkfs time when the default stripe count cannot fit in the inode core and #inodes > #blocks.
> Johann
> -- 
> Johann Lombardi
> Whamcloud, Inc.
> www.whamcloud.com
> _______________________________________________
> Lustre-devel mailing list
> Lustre-devel at lists.lustre.org
> http://lists.lustre.org/mailman/listinfo/lustre-devel

More information about the lustre-devel mailing list