<br>
<br>
<table width=100%>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">From:</font>
<td><font size=1 face="sans-serif">Eric Sandeen <sandeen@sandeen.net></font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">To:</font>
<td><font size=1 face="sans-serif">Adam Donald <Adam.Donald@gencopharma.com></font>
<tr>
<td valign=top><font size=1 color=#5f5f5f face="sans-serif">Cc:</font>
<td><font size=1 face="sans-serif">xfs@oss.sgi.com</font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">Date:</font>
<td><font size=1 face="sans-serif">06/29/2009 03:44 PM</font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">Subject:</font>
<td><font size=1 face="sans-serif">Re: Correct usage of inode64/running
out of inodes</font></table>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>Adam Donald wrote:<br>
<br>
> Thank you for your response. To be honest, I only ran out of
"space"<br>
> (inodes) once on this volume a month or so ago, and I recall receiving
a<br>
> ENOSPC type error at that time. At the time I received out of
space<br>
> errors I found the xfs_db command and have since started to monitor
the<br>
> ifree value, deleting files when I felt that ifree was dipping too
low,<br>
> as I was unable to apply the inode64 option without first taking down<br>
> various production systems. When the time came this past weekend
to<br>
> apply the inode64 option, I was expecting the ifree option value to<br>
> shoot up dramatically (several hundred, perhaps), and instead the
ifree<br>
> value remained unaffected, the same as mounting the volume without
the<br>
> inode64 option. <br>
<br>
I don't -think- that the inode64 option affects the value reported via<br>
statfs (though maybe it should; for dynamically allocated inodes it's<br>
all make-believe anyway)<br>
<br>
> Given the fact that I have this volume mounted with the inode64 option,<br>
> have roughly 7.5TB free, and show ifree with a double digit number<br>
> (currently 30 on our system), is there a an inconsistency between
the<br>
> total amount of free space available and the number of free inodes<br>
> available?<br>
<br>
hand-wavily, no, it seems fine... the way xfs reports free inodes (or<br>
available inodes) is to look at how many blocks are free, and then how<br>
many inodes -could- be created in that number of blocks, which is why<br>
it's often absurdly high numbers.<br>
<br>
inode32 behavior, fragmented free space, or lack of stripe-aligned space<br>
(I think...) can sometimes cause spurious ENOSPC when looking for a new<br>
inode...<br>
<br>
-Eric<br>
<br>
> Thanks again for the input, I appreciate it!<br>
> <br>
> <br>
> AD<br>
</font></tt>
<br><tt><font size=2>Again, I appreciated your input, and I am tending
to agree with you that our setup is now fine since adding inode64. I
noticed that I had an ifree value of 9 this morning and I then used dd
to create several large files. During the dd process the ifree value
jumped to 63 without sending a space error - it appears that the inode64
setting is indeed working as intended, I just had incorrect expectations
as to how this option would affect the actual display of ifree. Thank
you for helping me get this situation straightened out.</font></tt>
<br>
<br>
<br><tt><font size=2>AD<br>
</font></tt>
<br>
<br>
<BR>
______________________________________________________________________<BR>
This email has been scanned by the MessageLabs Email Security System.<BR>
For more information please visit http://www.messagelabs.com/email <BR>
______________________________________________________________________<BR>