<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1027" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">-Paul Sanchez<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> gpfsug-discuss-bounces@gpfsug.org [mailto:gpfsug-discuss-bounces@gpfsug.org]
<b>On Behalf Of </b>Zachary Giles<br>
<b>Sent:</b> Tuesday, March 17, 2015 11:49 AM<br>
<b>To:</b> gpfsug main discussion list<br>
<b>Subject:</b> Re: [gpfsug-discuss] Fragmented Inode Space and Performance of Policy Scans<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">I've always wondered also what the decision point is to make new inode tables per fileset. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">Sounds like the main benefit is scope of mmapplypolicy ( and other commands maybe ) and subblocks being grouped together for performance reasons. Is that right?<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal">Are there other benefits like portability or grouping a fileset's inode table into specific failure groups (in the system pool) etc?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">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 ? )<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">-Zach<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Tue, Mar 17, 2015 at 10:22 AM, Marc A Kaplan <<a href="mailto:makaplan@us.ibm.com" target="_blank">makaplan@us.ibm.com</a>> wrote:<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-family:"Arial","sans-serif"">Luke,
</span><br>
<br>
<span style="font-family:"Arial","sans-serif""> Thanks for your question. Independent filesets and their inodes are not implemented the way you might be imagining or guessing.</span>
<br>
<br>
<span style="font-family:"Arial","sans-serif"">Suppose you have two independent filesets "root" and "fset2" in the same GPFS file system.</span>
<br>
<span style="font-family:"Arial","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.</span> <br>
<br>
<span style="font-family:"Arial","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.</span> <br>
<br>
<span style="font-family:"Arial","sans-serif"">So there can be performance advantages to using independent filesets and restricting your mmapplypolicy scans to just the fileset you need.</span>
<br>
<span style="font-family:"Arial","sans-serif"">To gain maximal advantage, use the following form of the command:</span>
<br>
<br>
<span style="font-family:"Arial","sans-serif""> mmapplypolicy /gpfs/path-to-the-directory-tree-I-want-to-scan --scope {fileset | inodespace } ...</span>
<br>
<span style="font-family:"Arial","sans-serif""> </span><br>
<br>
<span style="font-family:"Arial","sans-serif"">An inodespace is the set of all inodes in an independent fileset. An inodespace may contain several "dependent" filesets. </span>
<br>
<br>
<span style="font-family:"Arial","sans-serif""><br>
</span><br>
<br>
<!--[if gte vml 1]><v:shapetype id="_x0000_t75" coordsize="21600,21600" o:spt="75" o:preferrelative="t" path="m@4@5l@4@11@9@11@9@5xe" filled="f" stroked="f">
<v:stroke joinstyle="miter" />
<v:formulas>
<v:f eqn="if lineDrawn pixelLineWidth 0" />
<v:f eqn="sum @0 1 0" />
<v:f eqn="sum 0 0 @1" />
<v:f eqn="prod @2 1 2" />
<v:f eqn="prod @3 21600 pixelWidth" />
<v:f eqn="prod @3 21600 pixelHeight" />
<v:f eqn="sum @0 0 1" />
<v:f eqn="prod @6 1 2" />
<v:f eqn="prod @7 21600 pixelWidth" />
<v:f eqn="sum @8 21600 0" />
<v:f eqn="prod @7 21600 pixelHeight" />
<v:f eqn="sum @10 21600 0" />
</v:formulas>
<v:path o:extrusionok="f" gradientshapeok="t" o:connecttype="rect" />
<o:lock v:ext="edit" aspectratio="t" />
</v:shapetype><v:shape id="_x0000_s1026" type="#_x0000_t75" alt="Marc A Kaplan" style='position:absolute;margin-left:0;margin-top:0;width:142.2pt;height:81pt;z-index:251658240;mso-wrap-distance-left:0;mso-wrap-distance-top:0;mso-wrap-distance-right:0;mso-wrap-distance-bottom:0;mso-position-horizontal:left;mso-position-horizontal-relative:text;mso-position-vertical-relative:line' o:allowoverlap="f">
<v:imagedata src="cid:image001.gif@01D060A9.415DA4E0" o:title="_1_098359D009835790004F023785257E0B" />
<w:wrap type="square"/>
</v:shape><![endif]--><![if !vml]><img src="cid:image001.gif@01D060A9.415DA4E0" align="left" alt="Marc A Kaplan" v:shapes="_x0000_s1026"><![endif]><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><o:p></o:p></p>
</div>
<p class="MsoNormal"><br>
<br clear="all">
<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">-- <o:p></o:p></p>
<div>
<p class="MsoNormal">Zach Giles<br>
<a href="mailto:zgiles@gmail.com">zgiles@gmail.com</a><o:p></o:p></p>
</div>
</div>
</div>
</body>
</html>