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
