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

[Sanchez, Paul]

It’s also required for per-fileset snapshots, which are useful if you have differing snapshot requirements or want the ability to flush high-churn snapshots that are consuming an unexpected amount of space, but with better resolution than a whole filesystem.

-Paul Sanchez

From: gpfsug-discuss-bounces at gpfsug.org [mailto:gpfsug-discuss-bounces at gpfsug.org] On Behalf Of Zachary Giles
Sent: Tuesday, March 17, 2015 11:49 AM
To: gpfsug main discussion list
Subject: Re: [gpfsug-discuss] Fragmented Inode Space and Performance of Policy Scans

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<mailto: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.




[Marc A Kaplan]
_______________________________________________
gpfsug-discuss mailing list
gpfsug-discuss at gpfsug.org<http://gpfsug.org>
http://gpfsug.org/mailman/listinfo/gpfsug-discuss



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