Hi Marc, Thanks for this information. One thing I still can't extract from the manual (though I guess I could just do a small experiment to find out) is whether the number of allocated inodes is automatically extended when running low, up to the maximum for an independent fileset?
Cheers, Luke. From: [email protected] [mailto:[email protected]] On Behalf Of Marc A Kaplan Sent: 17 March 2015 14:23 To: gpfsug main discussion list Subject: Re: [gpfsug-discuss] Fragmented Inode Space and Performance of Policy Scans 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. [Marc A Kaplan]
_______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at gpfsug.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
