Ah. that's a good point about the snapshots. On Tue, Mar 17, 2015 at 12:01 PM, Sanchez, Paul <[email protected]> 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:* [email protected] [mailto: > [email protected]] *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 <[email protected]> > 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 > [email protected] > > _______________________________________________ > gpfsug-discuss mailing list > gpfsug-discuss at gpfsug.org > http://gpfsug.org/mailman/listinfo/gpfsug-discuss > > -- Zach Giles [email protected]
_______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at gpfsug.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
