>>[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 <[email protected]> On Behalf Of Olaf Weiser Sent: Wednesday, August 2, 2023 7:43 AM To: [email protected] 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 <[email protected]<mailto:[email protected]>> im Auftrag von Peter Chase <[email protected]<mailto:[email protected]>> Gesendet: Mittwoch, 2. August 2023 11:09 An: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> 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
_______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at gpfsug.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss_gpfsug.org
