<font size=2 face="sans-serif">Its also important to look into the actual
space &quot;wasted&quot; by the &quot;subblock mismatch&quot;.</font><br><font size=2 face="sans-serif">For example, a snip from a filehist
output I've found somewhere:</font><br><br><font size=2 face="sans-serif"><i>File%ile represents the cummulative
percentage of files.</i></font><br><font size=2 face="sans-serif"><i>Space%ile represents the cummulative
percentage of total space used.</i></font><br><font size=2 face="sans-serif"><i>AvlSpc%ile represents the cummulative
percentage used of total available space.</i></font><br><br><font size=2 face="sans-serif"><i>Histogram of files &lt;= one 2M block
in size</i></font><br><font size=2 face="sans-serif"><i>Subblocks &nbsp; &nbsp;Count &nbsp;File%ile
&nbsp;Space%ile &nbsp; AvlSpc%ile</i></font><br><font size=2 face="sans-serif"><i>--------- -------- ---------- ----------
&nbsp;----------</i></font><br><font size=2 face="sans-serif"><i>&nbsp; &nbsp; &nbsp; &nbsp; 0 &nbsp;1297314
&nbsp; &nbsp; &nbsp;2.65% &nbsp; &nbsp; &nbsp;0.00% &nbsp; &nbsp; &nbsp;
0.00%</i></font><br><font size=2 face="sans-serif"><i>&nbsp; &nbsp; &nbsp; &nbsp; 1 34014892
&nbsp; &nbsp; 72.11% &nbsp; &nbsp; &nbsp;0.74% &nbsp; &nbsp; &nbsp; 0.59%</i></font><br><font size=2 face="sans-serif"><i>&nbsp; &nbsp; &nbsp; &nbsp; 2 &nbsp;2217365
&nbsp; &nbsp; 76.64% &nbsp; &nbsp; &nbsp;0.84% &nbsp; &nbsp; &nbsp; 0.67%</i></font><br><font size=2 face="sans-serif"><i>&nbsp; &nbsp; &nbsp; &nbsp; 3 &nbsp;1967998
&nbsp; &nbsp; 80.66% &nbsp; &nbsp; &nbsp;0.96% &nbsp; &nbsp; &nbsp; 0.77%</i></font><br><font size=2 face="sans-serif"><i>&nbsp; &nbsp; &nbsp; &nbsp; 4 &nbsp;
798170 &nbsp; &nbsp; 82.29% &nbsp; &nbsp; &nbsp;1.03% &nbsp; &nbsp; &nbsp;
0.83%</i></font><br><font size=2 face="sans-serif"><i>&nbsp; &nbsp; &nbsp; &nbsp; 5 &nbsp;1518258
&nbsp; &nbsp; 85.39% &nbsp; &nbsp; &nbsp;1.20% &nbsp; &nbsp; &nbsp; 0.96%</i></font><br><font size=2 face="sans-serif"><i>&nbsp; &nbsp; &nbsp; &nbsp; 6 &nbsp;
581539 &nbsp; &nbsp; 86.58% &nbsp; &nbsp; &nbsp;1.27% &nbsp; &nbsp; &nbsp;
1.02%</i></font><br><font size=2 face="sans-serif"><i>&nbsp; &nbsp; &nbsp; &nbsp; 7 &nbsp;
659969 &nbsp; &nbsp; 87.93% &nbsp; &nbsp; &nbsp;1.37% &nbsp; &nbsp; &nbsp;
1.10%</i></font><br><font size=2 face="sans-serif"><i>&nbsp; &nbsp; &nbsp; &nbsp; 8 &nbsp;1178798
&nbsp; &nbsp; 90.33% &nbsp; &nbsp; &nbsp;1.58% &nbsp; &nbsp; &nbsp; 1.27%</i></font><br><font size=2 face="sans-serif"><i>&nbsp; &nbsp; &nbsp; &nbsp; 9 &nbsp;
189220 &nbsp; &nbsp; 90.72% &nbsp; &nbsp; &nbsp;1.62% &nbsp; &nbsp; &nbsp;
1.30%</i></font><br><font size=2 face="sans-serif"><i>&nbsp; &nbsp; &nbsp; &nbsp;10 &nbsp;
130197 &nbsp; &nbsp; 90.98% &nbsp; &nbsp; &nbsp;1.64% &nbsp; &nbsp; &nbsp;
1.32%</i></font><br><br><br><font size=2 face="sans-serif">So, 72% of the files are smaller then
1 subblock ( 2M in the above case BTW). If, for example, we'll double it
- we will &quot;waste&quot; ~76% of the files, and if we'll push it to
16M it will be ~90% of the files...</font><br><font size=2 face="sans-serif">But, we really care about capacity,
right? So, going into the 16M extreme, we'll &quot;waste&quot; 1.58% of
the capacity ( worst case of course).</font><br><br><font size=2 face="sans-serif">So, if it will give you ( highly depends
on the workload of course) 4X the performance ( just for the sake of discussion)
- will it be OK to pay the 1.5% &quot;premium&quot; ?</font><br><br><br><font size=2 face="sans-serif"><br>Regards,<br><br>Tomer Perry<br>Scalable I/O Development (Spectrum Scale)<br>email: tomp@il.ibm.com<br>1 Azrieli Center, Tel Aviv 67021, Israel<br>Global Tel: &nbsp; &nbsp;+1 720 3422758<br>Israel Tel: &nbsp; &nbsp; &nbsp;+972 3 9188625<br>Mobile: &nbsp; &nbsp; &nbsp; &nbsp; +972 52 2554625<br></font><br><br><br><br><font size=1 color=#5f5f5f face="sans-serif">From: &nbsp; &nbsp; &nbsp;
&nbsp;</font><font size=1 face="sans-serif">&quot;Marc A Kaplan&quot;
&lt;makaplan@us.ibm.com&gt;</font><br><font size=1 color=#5f5f5f face="sans-serif">To: &nbsp; &nbsp; &nbsp;
&nbsp;</font><font size=1 face="sans-serif">gpfsug main discussion
list &lt;gpfsug-discuss@spectrumscale.org&gt;</font><br><font size=1 color=#5f5f5f face="sans-serif">Date: &nbsp; &nbsp; &nbsp;
&nbsp;</font><font size=1 face="sans-serif">10/04/2019 20:57</font><br><font size=1 color=#5f5f5f face="sans-serif">Subject: &nbsp; &nbsp;
&nbsp; &nbsp;</font><font size=1 face="sans-serif">Re: [gpfsug-discuss]
Follow-up: ESS File systems</font><br><font size=1 color=#5f5f5f face="sans-serif">Sent by: &nbsp; &nbsp;
&nbsp; &nbsp;</font><font size=1 face="sans-serif">gpfsug-discuss-bounces@spectrumscale.org</font><br><hr noshade><br><br><br><font size=2>If you're into pondering some more tweaks:</font><font size=3><br></font><font size=2><br>-i InodeSize &nbsp; is tunable</font><font size=3><br></font><font size=2><br>system pool : --metadata-block-size is tunable separately from &nbsp;-B
blocksize</font><font size=3><br></font><font size=2><br>On ESS you might want to use different block size and error correcting
codes for (v)disks that hold system pool.<br>Generally I think you'd want to set up system pool for best performance
for relatively short reads and updates.<br></font><font size=3><br></font><tt><font size=2>_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at spectrumscale.org<br></font></tt><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss"><tt><font size=2>http://gpfsug.org/mailman/listinfo/gpfsug-discuss</font></tt></a><tt><font size=2><br></font></tt><br><br><BR>