Correct usage of inode64/running out of inodes

[Adam Donald]

From:
Eric Sandeen <sandeen at sandeen.net>
To:
Adam Donald <Adam.Donald at gencopharma.com>
Cc:
xfs at oss.sgi.com
Date:
06/29/2009 03:44 PM
Subject:
Re: Correct usage of inode64/running out of inodes



Adam Donald wrote:

> Thank you for your response.  To be honest, I only ran out of "space"
> (inodes) once on this volume a month or so ago, and I recall receiving a
> ENOSPC type error at that time.  At the time I received out of space
> errors I found the xfs_db command and have since started to monitor the
> ifree value, deleting files when I felt that ifree was dipping too low,
> as I was unable to apply the inode64 option without first taking down
> various production systems.  When the time came this past weekend to
> apply the inode64 option, I was expecting the ifree option value to
> shoot up dramatically (several hundred, perhaps), and instead the ifree
> value remained unaffected, the same as mounting the volume without the
> inode64 option. 

I don't -think- that the inode64 option affects the value reported via
statfs (though maybe it should; for dynamically allocated inodes it's
all make-believe anyway)

> Given the fact that I have this volume mounted with the inode64 option,
> have roughly 7.5TB free, and show ifree with a double digit number
> (currently 30 on our system), is there a an inconsistency between the
> total amount of free space available and the number of free inodes
> available?

hand-wavily, no, it seems fine... the way xfs reports free inodes (or
available inodes) is to look at how many blocks are free, and then how
many inodes -could- be created in that number of blocks, which is why
it's often absurdly high numbers.

inode32 behavior, fragmented free space, or lack of stripe-aligned space
(I think...) can sometimes cause spurious ENOSPC when looking for a new
inode...

-Eric

> Thanks again for the input, I appreciate it!
> 
> 
> AD

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.


AD




______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://oss.sgi.com/pipermail/xfs/attachments/20090630/569ffc7b/attachment.htm>