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-boun...@spectrumscale.org> on behalf of "Buterbaugh, Kevin L" <kevin.buterba...@vanderbilt.edu> Reply-To: gpfsug main discussion list <gpfsug-discuss@spectrumscale.org> Date: Monday, August 6, 2018 at 11:37 AM To: gpfsug main discussion list <gpfsug-discuss@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.buterba...@vanderbilt.edu<mailto:kevin.buterba...@vanderbilt.edu> - (615)875-9633
_______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
