<div dir="ltr">2.8TB seems quite high for only 350M inodes.  Are you sure you only have metadata in there?</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 23, 2018 at 9:25 AM, Frederick Stock <span dir="ltr"><<a href="mailto:stockf@us.ibm.com" target="_blank">stockf@us.ibm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><font size="2" face="sans-serif">One possibility is the creation/expansion
of directories or allocation of indirect blocks for large files.</font><br><br><font size="2" face="sans-serif">Not sure if this is the issue here but
at one time inode allocation was considered slow and so folks may have
pre-allocated inodes to avoid that overhead during file creation.  To
my understanding inode creation time is not so slow that users need to
pre-allocate inodes.  Yes, there are likely some applications where
pre-allocating may be necessary but I expect they would be the exception.
 I mention this because you have a lot of free inodes and of course
once they are allocated they cannot be de-allocated.  </font><br><br><font size="3" face="sans-serif">Fred<br>______________________________<wbr>____________________<br>Fred Stock | IBM Pittsburgh Lab | <a href="tel:(720)%20430-8821" value="+17204308821" target="_blank">720-430-8821</a><br><a href="mailto:stockf@us.ibm.com" target="_blank">stockf@us.ibm.com</a></font><br><br><br><br><font size="1" color="#5f5f5f" face="sans-serif">From:      
 </font><font size="1" face="sans-serif">"Buterbaugh, Kevin
L" <Kevin.Buterbaugh@Vanderbilt.<wbr>Edu></font><span class=""><br><font size="1" color="#5f5f5f" face="sans-serif">To:      
 </font><font size="1" face="sans-serif">gpfsug main discussion
list <<a href="mailto:gpfsug-discuss@spectrumscale.org" target="_blank">gpfsug-discuss@spectrumscale.<wbr>org</a>></font><br></span><font size="1" color="#5f5f5f" face="sans-serif">Date:      
 </font><font size="1" face="sans-serif">01/23/2018 12:17 PM</font><span class=""><br><font size="1" color="#5f5f5f" face="sans-serif">Subject:    
   </font><font size="1" face="sans-serif">[gpfsug-discuss]
Metadata only system pool</font><br></span><font size="1" color="#5f5f5f" face="sans-serif">Sent by:    
   </font><font size="1" face="sans-serif"><a href="mailto:gpfsug-discuss-bounces@spectrumscale.org" target="_blank">gpfsug-discuss-bounces@<wbr>spectrumscale.org</a></font><br><hr noshade><div><div class="h5"><br><br><br><font size="3">Hi All, </font><br><br><font size="3">I was under the (possibly false) impression that if you
have a filesystem where the system pool contains metadata only then the
only thing that would cause the amount of free space in that pool to change
is the creation of more inodes … is that correct?  In other words,
given that I have a filesystem with 130 million free (but allocated) inodes:</font><br><br><font size="3">Inode Information</font><br><font size="3">-----------------</font><br><font size="3">Number of used inodes:       218635454</font><br><font size="3">Number of free inodes:       131364674</font><br><font size="3">Number of allocated inodes:  350000128</font><br><font size="3">Maximum number of inodes:    350000128</font><br><font size="3"><br>I would not expect that a user creating a few hundred or thousands of files
could cause a “no space left on device” error (which I’ve got one user
getting).  There’s plenty of free data space, BTW.</font><br><br><font size="3">Now my system pool is almost “full”:</font><br><br><font size="3">(pool total)           2.878T
                     
            34M (  0%)    
   140.9M ( 0%)</font><br><br><font size="3">But again, what - outside of me creating more inodes -
would cause that to change??</font><br><br><font size="3">Thanks…</font><br><br><font size="3">Kevin</font><br><br><font size="3">—</font><br><font size="3">Kevin Buterbaugh - Senior System Administrator</font><br><font size="3">Vanderbilt University - Advanced Computing Center for
Research and Education</font><br><a href="mailto:Kevin.Buterbaugh@vanderbilt.edu" target="_blank"><font size="3" color="blue"><u>Kevin.Buterbaugh@vanderbilt.<wbr>edu</u></font></a><font size="3">- <a href="tel:(615)%20875-9633" value="+16158759633" target="_blank">(615)875-9633</a></font><br><br><br></div></div><tt><font size="2">______________________________<wbr>_________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at <a href="http://spectrumscale.org" target="_blank">spectrumscale.org</a><br></font></tt><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=p_1XEUyoJ7-VJxF_w8h9gJh8_Wj0Pey73LCLLoxodpw&m=gou0xYZwz8M-5i8mT6Tthafi8JW2aMrzQGMK1hUEUls&s=jcHOB_vmJjE8PnrpfHqzMkm1nk6QWwkn2npTEP6kcKs&e=" target="_blank"><tt><font size="2">https://urldefense.proofpoint.<wbr>com/v2/url?u=http-3A__gpfsug.<wbr>org_mailman_listinfo_gpfsug-<wbr>2Ddiscuss&d=DwICAg&c=jf_<wbr>iaSHvJObTbx-siA1ZOg&r=p_<wbr>1XEUyoJ7-VJxF_w8h9gJh8_<wbr>Wj0Pey73LCLLoxodpw&m=<wbr>gou0xYZwz8M-<wbr>5i8mT6Tthafi8JW2aMrzQGMK1hUEUl<wbr>s&s=jcHOB_<wbr>vmJjE8PnrpfHqzMkm1nk6QWwkn2npT<wbr>EP6kcKs&e=</font></tt></a><tt><font size="2"><br></font></tt><br><br><br>
<br>______________________________<wbr>_________________<br>
gpfsug-discuss mailing list<br>
gpfsug-discuss at <a href="http://spectrumscale.org" rel="noreferrer" target="_blank">spectrumscale.org</a><br>
<a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss" rel="noreferrer" target="_blank">http://gpfsug.org/mailman/<wbr>listinfo/gpfsug-discuss</a><br>
<br></blockquote></div><br></div>