<font size=2 face="sans-serif">If one were starting over, it might make
sense to use a smaller inode size. I believe we still support
512, 1K, 2K.</font><br><font size=2 face="sans-serif">Tradeoff with the fact that inodes can
store data and EAs.<br></font><br><br><br><br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">"Uwe Falke"
<UWEFALKE@de.ibm.com></font><br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">gpfsug main discussion
list <gpfsug-discuss@spectrumscale.org></font><br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">01/23/2018 04:04 PM</font><br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [gpfsug-discuss]
Metadata only system pool</font><br><font size=1 color=#5f5f5f face="sans-serif">Sent by:
</font><font size=1 face="sans-serif">gpfsug-discuss-bounces@spectrumscale.org</font><br><hr noshade><br><br><br><tt><font size=2>rough calculation (assuming 4k inodes): <br>350 x 10^6 x 4096 Bytes=1.434TB=1.304TiB. With replication that uses <br>2.877TB or 2.308TiB <br>As already mentioned here, directory and indirect blocks come on top. Even
<br>if you could get rid of a portion of the allocated and unused inodes that
<br>metadata pool appears bit small to me. <br>If that is a large filesystem there should be some funding to extend it.
<br>If you have such a many-but-small-files system as discussed recently in
<br>this theatre, you might still beg for more MD storage but that makes than
<br>a larger portion of the total cost (assuming data storage is on HDD and
md <br>storage on SSD) and that again reduces your chances. <br><br><br><br> <br>Mit freundlichen Grüßen / Kind regards<br><br> <br>Dr. Uwe Falke<br> <br>IT Specialist<br>High Performance Computing Services / Integrated Technology Services /
<br>Data Center Services<br>-------------------------------------------------------------------------------------------------------------------------------------------<br>IBM Deutschland<br>Rathausstr. 7<br>09111 Chemnitz<br>Phone: +49 371 6978 2165<br>Mobile: +49 175 575 2877<br>E-Mail: uwefalke@de.ibm.com<br>-------------------------------------------------------------------------------------------------------------------------------------------<br>IBM Deutschland Business & Technology Services GmbH / Geschäftsführung:
<br>Thomas Wolter, Sven Schooß<br>Sitz der Gesellschaft: Ehningen / Registergericht: Amtsgericht Stuttgart,
<br>HRB 17122 <br><br><br><br><br>From: "Buterbaugh, Kevin L" <Kevin.Buterbaugh@Vanderbilt.Edu><br>To: gpfsug main discussion list <gpfsug-discuss@spectrumscale.org><br>Date: 01/23/2018 06:17 PM<br>Subject: [gpfsug-discuss] Metadata only system
pool<br>Sent by: gpfsug-discuss-bounces@spectrumscale.org<br><br><br><br>Hi All, <br><br>I was under the (possibly false) impression that if you have a filesystem
<br>where the system pool contains metadata only then the only thing that <br>would cause the amount of free space in that pool to change is the <br>creation of more inodes ? is that correct? In other words, given
that I <br>have a filesystem with 130 million free (but allocated) inodes:<br><br>Inode Information<br>-----------------<br>Number of used inodes: 218635454<br>Number of free inodes: 131364674<br>Number of allocated inodes: 350000128<br>Maximum number of inodes: 350000128<br><br>I would not expect that a user creating a few hundred or thousands of <br>files could cause a ?no space left on device? error (which I?ve got one
<br>user getting). There?s plenty of free data space, BTW.<br><br>Now my system pool is almost ?full?:<br><br>(pool total) 2.878T
34M ( 0%) <br> 140.9M ( 0%)<br><br>But again, what - outside of me creating more inodes - would cause that
to <br>change??<br><br>Thanks?<br><br>Kevin<br><br>?<br>Kevin Buterbaugh - Senior System Administrator<br>Vanderbilt University - Advanced Computing Center for Research and <br>Education<br>Kevin.Buterbaugh@vanderbilt.edu - (615)875-9633<br><br><br>_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at spectrumscale.org<br></font></tt><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss&d=DwIFAw&c=jf_iaSHvJObTbx-siA1ZOg&r=cvpnBBH0j41aQy0RPiG2xRL_M8mTc1izuQD3_PmtjZ8&m=8WgQlUnhzFycOZf-YvqYpdUkCiyEdRvWukE-KKRuFbE&s=aCywbK-1heVHPR8Fg74z9VxkGbNfCxMdtEKIDMWVIwI&e="><tt><font size=2>https://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss&d=DwIFAw&c=jf_iaSHvJObTbx-siA1ZOg&r=cvpnBBH0j41aQy0RPiG2xRL_M8mTc1izuQD3_PmtjZ8&m=8WgQlUnhzFycOZf-YvqYpdUkCiyEdRvWukE-KKRuFbE&s=aCywbK-1heVHPR8Fg74z9VxkGbNfCxMdtEKIDMWVIwI&e=</font></tt></a><tt><font size=2><br><br><br><br><br>_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at spectrumscale.org<br></font></tt><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss&d=DwIFAw&c=jf_iaSHvJObTbx-siA1ZOg&r=cvpnBBH0j41aQy0RPiG2xRL_M8mTc1izuQD3_PmtjZ8&m=8WgQlUnhzFycOZf-YvqYpdUkCiyEdRvWukE-KKRuFbE&s=aCywbK-1heVHPR8Fg74z9VxkGbNfCxMdtEKIDMWVIwI&e="><tt><font size=2>https://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss&d=DwIFAw&c=jf_iaSHvJObTbx-siA1ZOg&r=cvpnBBH0j41aQy0RPiG2xRL_M8mTc1izuQD3_PmtjZ8&m=8WgQlUnhzFycOZf-YvqYpdUkCiyEdRvWukE-KKRuFbE&s=aCywbK-1heVHPR8Fg74z9VxkGbNfCxMdtEKIDMWVIwI&e=</font></tt></a><tt><font size=2><br><br></font></tt><br><br><BR>