<div dir="ltr"><div>I've always wondered also what the decision point is to make new inode tables per fileset. </div><div><br></div>Sounds like the main benefit is scope of mmapplypolicy ( and other commands maybe ) and subblocks being grouped together for performance reasons. Is that right?<div><div>Are there other benefits like portability or grouping a fileset's inode table into specific failure groups (in the system pool) etc?</div><div>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 ? )</div><div><br></div><div>-Zach</div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 17, 2015 at 10:22 AM, Marc A Kaplan <span dir="ltr"><<a href="mailto:makaplan@us.ibm.com" target="_blank">makaplan@us.ibm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><font face="sans-serif">Luke, </font>
<br>
<br><font face="sans-serif">  Thanks for your question.  Independent
filesets and their inodes are not implemented the way you might be imagining
or guessing.</font>
<br>
<br><font face="sans-serif">Suppose you have two independent filesets
"root" and "fset2" in the same GPFS file system.</font>
<br><font face="sans-serif">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.</font>
<br>
<br><font face="sans-serif">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.</font>
<br>
<br><font face="sans-serif">So there can be performance advantages
to using independent filesets and restricting your mmapplypolicy scans
to just the fileset you need.</font>
<br><font face="sans-serif">To gain maximal advantage, use the following
form of the command:</font>
<br>
<br><font face="sans-serif">   mmapplypolicy /gpfs/path-to-the-directory-tree-I-want-to-scan
 --scope {fileset | inodespace }  ...</font>
<br><font face="sans-serif">  </font>
<br>
<br><font face="sans-serif">An inodespace is the set of all inodes
in an independent fileset.  An inodespace may contain several "dependent"
filesets.  </font>
<br>
<br><font face="sans-serif"><br>
</font>
<br>
<br><img align="left" src="cid:_1_098359D009835790004F023785257E0B" alt="Marc A Kaplan" style="border:0px solid"><br>_______________________________________________<br>
gpfsug-discuss mailing list<br>
gpfsug-discuss at <a href="http://gpfsug.org" target="_blank">gpfsug.org</a><br>
<a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss" target="_blank">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Zach Giles<br><a href="mailto:zgiles@gmail.com">zgiles@gmail.com</a></div>
</div>