[gpfsug-discuss] Fragmented Inode Space and Performance of Policy Scans

[Zachary Giles]

I've always wondered also what the decision point is to make new inode
tables per fileset.

Sounds like the main benefit is scope of mmapplypolicy ( and other commands
maybe ) and subblocks being grouped together for performance reasons. Is
that right?
Are there other benefits like portability or grouping a fileset's inode
table into specific failure groups (in the system pool) etc?
Any downsides? ( for example: now you have more overall metadata reads.. or
only a limited number of inode tables.. or total number of inodes in the
system is higher due to overallocation on N tables ? )

-Zach


On Tue, Mar 17, 2015 at 10:22 AM, Marc A Kaplan <makaplan at us.ibm.com> wrote:

> Luke,
>
>   Thanks for your question.  Independent filesets and their inodes are not
> implemented the way you might be imagining or guessing.
>
> Suppose you have two independent filesets "root" and "fset2" in the same
> GPFS file system.
> It is true that all the inode records (typically 512 bytes each - see
> mmcrfs) go into the same special file.  BUT if you look at any given
> metadata allocation block --metadata-block-size (defaults to 256K) you'll
> only see inodes for either "root" or "fset2" not both in the same block.
>
> Moreover we try to "pre"-allocate several blocks of inodes for the same
> independent fileset contiguously - so that typically GPFS can do one seek
> and then read several blocks of inodes from the same independent fileset.
>
> So there can be performance advantages to using independent filesets and
> restricting your mmapplypolicy scans to just the fileset you need.
> To gain maximal advantage, use the following form of the command:
>
>    mmapplypolicy /gpfs/path-to-the-directory-tree-I-want-to-scan  --scope
> {fileset | inodespace }  ...
>
>
> An inodespace is the set of all inodes in an independent fileset.  An
> inodespace may contain several "dependent" filesets.
>
>
>
>
> [image: Marc A Kaplan]
> _______________________________________________
> gpfsug-discuss mailing list
> gpfsug-discuss at gpfsug.org
> http://gpfsug.org/mailman/listinfo/gpfsug-discuss
>
>


-- 
Zach Giles
zgiles at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20150317/669b16ea/attachment-0003.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 21994 bytes
Desc: not available
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20150317/669b16ea/attachment-0003.gif>