<font size=2 face="sans-serif">Metadata is inodes, directories, indirect
blocks (indices). </font><br><br><font size=2 face="sans-serif">Spectrum Scale (GPFS) Version 4.1 introduced
significant improvements to the data structures used to represent directories.</font><br><font size=2 face="sans-serif">Larger inodes supporting data and extended
attributes in the inode are other significant relatively recent improvements.</font><br><br><font size=2 face="sans-serif">Now small directories are stored in
the inode, while for large directories blocks can be bigger than 32MB,
and any and all directory blocks that are smaller than</font><br><font size=2 face="sans-serif">the metadata-blocksize, are allocated
just like "fragments" - so directories are now space efficient.</font><br><br><font size=2 face="sans-serif">SO MUCH SO, that THE OLD ADVICE, about
using smallish blocksizes for metadata, GOES "OUT THE WINDOW".
Period. FORGET most of what you thought</font><br><font size=2 face="sans-serif">you knew about "best" or "optimal"
metadata-blocksize.</font><br><br><font size=2 face="sans-serif">The new advice is, as Sven wrote: </font><br><br><font size=2 face="sans-serif">Use a blocksize that optimizes IO transfer
efficiency and speed.</font><br><font size=2 face="sans-serif">This is true for BOTH data and metadata.</font><br><br><font size=2 face="sans-serif">Now, IF you have system pool set up
as metadata only AND system pool is on devices that have a different "optimal"
block size than your other pools,</font><br><font size=2 face="sans-serif">THEN, it may make sense to use two different
blocksizes, one for data and another for metadata.</font><br><br><font size=2 face="sans-serif">For example, maybe you have massively
striped RAID or RAID-LIKE (GSS or ESS)) storage for huge files - so maybe
8MB is a good blocksize for that.</font><br><font size=2 face="sans-serif">But maybe you have your metadata on
SSD devices and maybe 1MB is the "best" blocksize for that.<br></font><BR>