<div dir="auto"><div>I think things are conflated here...</div><div dir="auto"><br></div><div dir="auto">The inode size is really just a call on how much functionality you need in an inode.  I wouldn't even think about disk block size when setting this.  Essentially the smaller the inode the less space I need for metadata but also the less capacity I have in my inode.</div><div dir="auto"><br></div><div dir="auto"><div dir="auto">The default is 4k and if you don't change it then GPFS will put up to a 3.8k file in the inode itself vs going to an indirect disk allocation.  Someone mentioned encryption will bypass this feature, but it's actually encryption that perhaps requires larger inode sizes to store all the key meta info (you can have up to 8 keys per inode I believe).</div><div dir="auto"><br></div><div dir="auto">So essentially it you've got a smaller inode size your directories max size will max out sooner, your ACLs could be constrained, large file names can exhaust, you may not have enough space for Encryption details.  But the upshot is you need to dedicate less space to metadata and can handle more file entries.  So if you've got billions of files and are managing replicas then you should consider fine tuning inode size down.</div><div dir="auto"><br></div><div dir="auto">You can go from 3.5% of space going to inodes to 1% if you went from 4k to 512 bytes.. but there is a reason GPFS defaults to 4k... And doesn't expand on it too much.  If you've guessed wrong you're kind of hosed.</div><div dir="auto"><br></div><div dir="auto">None of this has to do with hardware block sizes, subblock allocation and fragment sizes.  And further compounded by 4k native block sizes vs emulated 512 block size some disk hardware does.</div><div dir="auto"><br></div><div dir="auto">For GPFS you generally will have a very large block size 256kb or 1MB and GPFS will divide those blocks into 32 fragments.  So you may have your smallest unit being a 8kb or 32kb fragment.  If you have a dedicated MD pool (highly recommended) you'd definitely specify a smaller block size than 1MB (128kb = 4kb fragments).</div><div dir="auto"><br></div><div dir="auto">The balance you're trying to strike here is the least amount of commands to retrieve your data efficiently.  Think about the roundtrip on the bus being the same for a 4kb read vs a 1mb read so try to maximize this.</div><div dir="auto"><br></div><div dir="auto">Generally the goal of the file system is to ensure that the excess data that is read when trying to pull fragments is as useless as possible.</div><div dir="auto"><br></div><div dir="auto">I may also be confused but I wouldn't worry so much about inode size to block size.. just worry about getting large blocks working well for regular storage pool if your data is huge and using a smaller block size in MD if dedicate pool which is almost always recommended.</div><div dir="auto"><br></div><div dir="auto">Be very careful of specifying a small inode size because it's not just max filenames and max file counts in a directory.. it is much more.. and if you have a lot of small files don't underestimate the advantage of those files being stored directly in the inode.  A 512 byte inode could only store about a 380byte file vs a 4k file storing 3800 byte file.  These files tend to be shell scripts and config files which you really don't want to be waiting around for and occupying a huge 1mb read for and waisting a potentially larger 64kb fragment allocation on.</div><div dir="auto"><br></div><div dir="auto">Alec</div><div dir="auto"><br></div><div dir="auto"><br></div></div><div dir="auto"><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Wed, Aug 2, 2023, 4:47 AM Olaf Weiser <<a href="mailto:olaf.weiser@de.ibm.com" target="_blank" rel="noreferrer">olaf.weiser@de.ibm.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">




<div dir="ltr">
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
Hallo Peter, <br>
</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<span style="font-family:Arial,Helvetica,sans-serif;font-size:10pt;color:rgb(0,0,0)"><span><span style="display:inline!important;background-color:rgb(255,255,255)">[1]
<i>[...] having a smaller inode size than the subblock size means</i></span><i> there's a big wastage on disk usage, with no performance benefit to doing so[...]
<br>
</i></span></span></div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<span style="font-family:Arial,Helvetica,sans-serif;font-size:10pt;color:rgb(0,0,0)"><span>in short - yes 😉
<br>
</span></span></div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<span style="font-family:Arial,Helvetica,sans-serif;font-size:10pt;color:rgb(0,0,0)"><span><br>
</span></span></div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<span style="font-family:Arial,Helvetica,sans-serif;font-size:10pt;color:rgb(0,0,0)"><span><br>
</span></span></div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<span style="font-family:Arial,Helvetica,sans-serif;font-size:10pt;color:rgb(0,0,0)"><span><br>
</span></span></div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<span style="font-family:Arial,Helvetica,sans-serif;font-size:10pt;color:rgb(0,0,0)"><span>[2] 
<i>[...]  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.[...]
<br>
</i></span></span></div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<span style="font-family:Arial,Helvetica,sans-serif;font-size:10pt;color:rgb(0,0,0)"><span>you may need to consider snapshots and directories , which all contributes to MD space</span></span></div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<span style="font-family:Arial,Helvetica,sans-serif;font-size:10pt;color:rgb(0,0,0)"><span> <br>
</span></span></div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<span style="font-family:Arial,Helvetica,sans-serif;font-size:10pt;color:rgb(0,0,0)"><span>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... <br>
</span></span></div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<span style="font-family:Arial,Helvetica,sans-serif;font-size:10pt;color:rgb(0,0,0)"><span><br>
</span></span></div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<span style="font-family:Arial,Helvetica,sans-serif;font-size:10pt;color:rgb(0,0,0)"><span><br>
</span></span></div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<span style="font-family:Arial,Helvetica,sans-serif;font-size:10pt;color:rgb(0,0,0)"><span>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)
<br>
</span></span></div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<span style="font-family:Arial,Helvetica,sans-serif;font-size:10pt;color:rgb(0,0,0)"><span><br>
</span></span></div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<span style="font-family:Arial,Helvetica,sans-serif;font-size:10pt;color:rgb(0,0,0)"><span><br>
</span></span></div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<span style="font-family:Arial,Helvetica,sans-serif;font-size:10pt;color:rgb(0,0,0)"><span>hope this helps ..
<br>
</span></span></div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<span style="font-family:Arial,Helvetica,sans-serif;font-size:10pt;color:rgb(0,0,0)"><span><br>
</span></span></div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<span style="font-family:Arial,Helvetica,sans-serif;font-size:10pt;color:rgb(0,0,0)"><span><br>
</span></span></div>
<div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div id="m_-7736005608686638624m_735502529790437196Signature">
<div><br>
<br>
</div>
</div>
</div>
<div id="m_-7736005608686638624m_735502529790437196appendonsend"></div>
<hr style="display:inline-block;width:98%">
<div id="m_-7736005608686638624m_735502529790437196divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>Von:</b> gpfsug-discuss <<a href="mailto:gpfsug-discuss-bounces@gpfsug.org" rel="noreferrer noreferrer" target="_blank">gpfsug-discuss-bounces@gpfsug.org</a>> im Auftrag von Peter Chase <<a href="mailto:peter.chase@metoffice.gov.uk" rel="noreferrer noreferrer" target="_blank">peter.chase@metoffice.gov.uk</a>><br>
<b>Gesendet:</b> Mittwoch, 2. August 2023 11:09<br>
<b>An:</b> <a href="mailto:gpfsug-discuss@gpfsug.org" rel="noreferrer noreferrer" target="_blank">gpfsug-discuss@gpfsug.org</a> <<a href="mailto:gpfsug-discuss@gpfsug.org" rel="noreferrer noreferrer" target="_blank">gpfsug-discuss@gpfsug.org</a>><br>
<b>Betreff:</b> [EXTERNAL] [gpfsug-discuss] Inode size, and system pool subblock</font>
<div> </div>
</div>
<div>
<div style="display:none!important;display:none;font-size:1px;color:#ffffff;line-height:1px;height:0px;max-height:0px;opacity:0;overflow:hidden">
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,
</div>
<div style="display:none!important;display:none;font-size:1px;color:#ffffff;line-height:1px;height:0px;max-height:0px;opacity:0;overflow:hidden">
ZjQcmQRYFpfptBannerStart</div>
<div dir="ltr" lang="en" id="m_-7736005608686638624m_735502529790437196x_pfptBannerdou9crz" style="display:block!important;text-align:left!important;margin:16px 0px 16px 0px!important;padding:8px 16px 8px 16px!important;border-radius:4px!important;min-width:200px!important;background-color:#d0d8dc!important;background-color:#d0d8dc;border-top:4px solid #90a4ae!important;border-top:4px solid #90a4ae">
<div id="m_-7736005608686638624m_735502529790437196x_pfptBannerdou9crz" style="float:left!important;display:block!important;margin:0px 0px 1px 0px!important;max-width:600px!important">
<div id="m_-7736005608686638624m_735502529790437196x_pfptBannerdou9crz" style="display:block!important;background-color:#d0d8dc!important;color:#000000!important;color:#000000;font-family:'Arial',sans-serif!important;font-family:'Arial',sans-serif;font-weight:bold!important;font-weight:bold;font-size:14px!important;line-height:18px!important;line-height:18px">
This Message Is From an External Sender </div>
<div id="m_-7736005608686638624m_735502529790437196x_pfptBannerdou9crz" style="display:block!important;background-color:#d0d8dc!important;color:#000000!important;color:#000000;font-weight:normal;font-family:'Arial',sans-serif!important;font-family:'Arial',sans-serif;font-size:12px!important;line-height:18px!important;line-height:18px;margin-top:2px!important">
This message came from outside your organization. </div>
</div>
<div id="m_-7736005608686638624m_735502529790437196x_pfptBannerdou9crz" style="float:right!important;display:block!important;display:block;margin:0px 0px 0px 16px!important;text-align:right!important;width:fit-content!important">
<a id="m_-7736005608686638624m_735502529790437196x_pfptBannerdou9crz" href="https://us-phishalarm-ewt.proofpoint.com/EWT/v1/PjiDSg!1g-uTV5zSvlaFYv7uMHkoFeQxN2NCCmKt8m8bO-cETpoqWzqjw44ZGDhXsa5HhRl_zpqhYnKttgvkXxxkccvwPudkw6wVRSXHaJbtLOtA_jXzsNaKGOzzQZE69zpJnR6tbWVCjgrkUVf$" style="display:inline-block!important;text-decoration:none" rel="noreferrer noreferrer" target="_blank">
<div style="display:inline-block!important;display:inline-block;opacity:1!important;color:#000000!important;color:#000000;font-family:'Arial',sans-serif!important;font-family:'Arial',sans-serif;font-size:14px!important;font-weight:normal!important;text-decoration:none!important;border-radius:2px!important;padding:7.5px 16px!important;margin:3px 0 3px 16px!important;white-space:nowrap!important;width:fit-content!important;border:1px solid #666666">
Report Suspicious </div>
</a></div>
<div style="clear:both!important;display:block!important;line-height:0!important;font-size:0.01px!important;height:0px">
 </div>
</div>
<div style="display:none!important;display:none;font-size:1px;color:#ffffff;line-height:1px;height:0px;max-height:0px;opacity:0;overflow:hidden">
ZjQcmQRYFpfptBannerEnd</div>

<div style="font-family:Arial,Helvetica,sans-serif;font-size:10pt;color:rgb(0,0,0)">
Good Morning,</div>
<div style="font-family:Arial,Helvetica,sans-serif;font-size:10pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Arial,Helvetica,sans-serif;font-size:10pt;color:rgb(0,0,0)">
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?</div>
<div style="font-family:Arial,Helvetica,sans-serif;font-size:10pt;color:rgb(0,0,0)">
I'm looking at an existing filesystem, the inode size is 2KiB, and the subblock is 4KiB.</div>
<div style="font-family:Arial,Helvetica,sans-serif;font-size:10pt;color:rgb(0,0,0)">
It feels like I'm missing something. <span style="font-family:Arial,Helvetica,sans-serif;font-size:10pt">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), <span style="display:inline!important;color:rgb(0,0,0);background-color:rgb(255,255,255)">having
 a smaller inode size than the subblock size means</span> there's a big wastage on disk usage, with no performance benefit to doing so.</span></div>
<div style="font-family:Arial,Helvetica,sans-serif;font-size:10pt;color:rgb(0,0,0)">
<span style="font-family:Arial,Helvetica,sans-serif;font-size:10pt">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.</span></div>
<div>
<div style="font-family:Arial,Helvetica,sans-serif;font-size:10pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Arial,Helvetica,sans-serif;font-size:10pt;color:rgb(0,0,0)">
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!</div>
<div style="font-family:Arial,Helvetica,sans-serif;font-size:10pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Arial,Helvetica,sans-serif;font-size:10pt;color:rgb(0,0,0)">
Sincerely,</div>
<div style="font-family:Arial,Helvetica,sans-serif;font-size:10pt;color:rgb(0,0,0)">
<br>
</div>
<div id="m_-7736005608686638624m_735502529790437196x_Signature">
<div>
<div></div>
<div id="m_-7736005608686638624m_735502529790437196x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt;color:rgb(0,0,0)">
<p style="font-family:Calibri,Helvetica,sans-serif;margin-top:0px;margin-bottom:0px">
<span style="font-size:10pt;font-family:Arial,sans-serif,serif,EmojiFont;color:black"><span style="font-size:10pt;font-family:Arial,Helvetica,sans-serif;color:rgb(0,0,0)">Pete Chase</span><br>
</span></p>
<p style="margin-top:0px;margin-bottom:0px"><span style="font-size:10pt;color:black"><font face="Arial, Helvetica, sans-serif">UKMO</font></span></p>
</div>
</div>
</div>
</div>
</div>
</div>

_______________________________________________<br>
gpfsug-discuss mailing list<br>
gpfsug-discuss at <a href="http://gpfsug.org" rel="noreferrer noreferrer noreferrer" target="_blank">gpfsug.org</a><br>
<a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss_gpfsug.org" rel="noreferrer noreferrer noreferrer" target="_blank">http://gpfsug.org/mailman/listinfo/gpfsug-discuss_gpfsug.org</a><br>
</blockquote></div>
</div></div>