[gpfsug-discuss] Inode size, and system pool subblock

Kidger, Daniel daniel.kidger at hpe.com
Wed Aug 2 12:56:32 BST 2023


Peter,
  "Meaning with a 4K subblock, and a 2K inode, reading the inode would return its contents and 2K of empty subblock every time"

I believe that a 2k inode *does* save space, hence more files in the filesystem for a given size of the system metadata pool.
However with modern 4k disk block sizes, you pay the price of a performance penalty.
Hence unless space constrained, you should use 4k inodes always.
Also remember that GPFS supports Data-on-Metadata (DoM in Lustre-speak), so 4k inodes can store small files (up to c. 3k), and so save significant space in the data pools (where the subblock size is at least 8kB and in your case probably 128kB.

Daniel Kidger
HPC Storage Solutions Architect, EMEA
daniel.kidger at hpe.com<mailto:daniel.kidger at hpe.com>

+44 (0)7818 522266

hpe.com<http://www.hpe.com/>


[cid:image001.png at 01D9C540.C15BD4A0]

From: gpfsug-discuss <gpfsug-discuss-bounces at gpfsug.org> On Behalf Of Peter Chase
Sent: 02 August 2023 10:10
To: gpfsug-discuss at gpfsug.org
Subject: [gpfsug-discuss] Inode size, and system pool subblock

Good Morning,

I have a question about inode size vs subblock size. Can anyone think of a reason that the chosen inode size of a scale filesystem should be smaller than the subblock size for the metadata pool?
I'm looking at an existing filesystem, the inode size is 2KiB, and the subblock is 4KiB.
It feels like I'm missing something. If I've understood the docs on blocks and subblocks correctly, it sounds like the subblock is the smallest atomic access size. Meaning with a 4K subblock, and a 2K inode, reading the inode would return its contents and 2K of empty subblock every time. So, in my head (and maybe only there), having a smaller inode size than the subblock size means there's a big wastage on disk usage, with no performance benefit to doing so.
I believe I'm correct in saying that inodes are not the only things to live on the metadata pool, so I assume that some other metadata might benefit from the larger block/subblock size. But looking at the number of inodes, the inode size, and the space consumed in the system pool, it really looks like the majority of space consumed is by inodes.

As I said, I feel like I'm missing something, so if anyone can tell me where I'm wrong it would be greatly appreciated!

Sincerely,


Pete Chase

UKMO
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20230802/ca27035b/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 2541 bytes
Desc: image001.png
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20230802/ca27035b/attachment.png>


More information about the gpfsug-discuss mailing list