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

Marc A Kaplan makaplan at us.ibm.com
Tue Mar 17 14:22:58 GMT 2015


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. 




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20150317/46873861/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 21994 bytes
Desc: not available
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20150317/46873861/attachment.gif>


More information about the gpfsug-discuss mailing list