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

[Zachary Giles]

Ah. that's a good point about the snapshots.

On Tue, Mar 17, 2015 at 12:01 PM, Sanchez, Paul <Paul.Sanchez at deshaw.com>
wrote:

>  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>
> 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
>
> _______________________________________________
> 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/c7c41782/attachment-0003.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 21994 bytes
Desc: not available
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20150317/c7c41782/attachment-0003.gif>