[gpfsug-discuss] Sub-block size not quite as expected on GPFS 5 filesystem?

[Hoang Nguyen]

That comment in the Administration guide is a legacy comment when Metadata sub-block size was restricted to 1/32 of the Metadata block size. In the past, creating large Metadata block sizes also meant large sub-blocks and hence large directory blocks which wasted a lot of space.

From: <gpfsug-discuss-bounces at spectrumscale.org> on behalf of "Buterbaugh, Kevin L" <Kevin.Buterbaugh at Vanderbilt.Edu>
Reply-To: gpfsug main discussion list <gpfsug-discuss at spectrumscale.org>
Date: Monday, August 6, 2018 at 11:37 AM
To: gpfsug main discussion list <gpfsug-discuss at spectrumscale.org>
Subject: Re: [gpfsug-discuss] Sub-block size not quite as expected on GPFS 5 filesystem?

Hi All,

So I was just reading the GPFS 5.0.0 Administration Guide (yes, I actually do look at the documentation even if it seems sometimes that I don’t!) for some other information and happened to come across this at the bottom of page 358:

The --metadata-block-size flag on the mmcrfs command can be used to create a system pool with a different block size from the user pools. This can be especially beneficial if the default block size is larger than 1 MB. If data and metadata block sizes differ, the system pool must contain only metadataOnly disks.
Given that one of the responses I received during this e-mail thread was from an IBM engineer basically pointing out that there is no benefit in setting the metadata-block-size to less than 4 MB if that’s what I want for the filesystem block size, this might be a candidate for a documentation update.

Thanks…

Kevin

—
Kevin Buterbaugh - Senior System Administrator
Vanderbilt University - Advanced Computing Center for Research and Education
Kevin.Buterbaugh at vanderbilt.edu<mailto:Kevin.Buterbaugh at vanderbilt.edu> - (615)875-9633




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20180806/037cb9e8/attachment-0002.htm>