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

[Wahl, Edward]

>>[2]  [...]  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.[...]

>you may need to consider snapshots and directories , which all contributes to MD space
>predicting the space requirements for MD for directories is always hard, because the size of a directory  is depending on the file's name length, the users will create...


Unless you enable encryption.  In which case NO metadata will be stored on MD disks/devices.

Ed Wahl
Ohio Supercomputer Center


From: gpfsug-discuss <gpfsug-discuss-bounces at gpfsug.org> On Behalf Of Olaf Weiser
Sent: Wednesday, August 2, 2023 7:43 AM
To: gpfsug-discuss at gpfsug.org
Subject: Re: [gpfsug-discuss] Inode size, and system pool subblock

Hallo Peter, [1] [. . . ] 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[. . . ] in short - yes 😉 [2] [. . . ] I believe I'm correct in saying that inodes are not

Hallo Peter,

[1] [...] 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[...]
in short - yes 😉



[2]  [...]  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.[...]
you may need to consider snapshots and directories , which all contributes to MD space

predicting the space requirements for MD for directories is always hard, because the size of a directory  is depending on the file's name length, the users will create...


further more,  using a less than 4k  inode size makes also not much sense, when taking into account, that NVMEs and other modern block storage devices comes with a hardware block size of 4k (even though GPFS still can deal with 512 Bytes per sector)


hope this helps ..




________________________________
Von: gpfsug-discuss <gpfsug-discuss-bounces at gpfsug.org<mailto:gpfsug-discuss-bounces at gpfsug.org>> im Auftrag von Peter Chase <peter.chase at metoffice.gov.uk<mailto:peter.chase at metoffice.gov.uk>>
Gesendet: Mittwoch, 2. August 2023 11:09
An: gpfsug-discuss at gpfsug.org<mailto:gpfsug-discuss at gpfsug.org> <gpfsug-discuss at gpfsug.org<mailto:gpfsug-discuss at gpfsug.org>>
Betreff: [EXTERNAL] [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,

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/a8fd9f5f/attachment-0001.htm>