|To:||Eric Sandeen <sandeen@xxxxxxxxxxx>|
|Subject:||Re: Correct usage of inode64/running out of inodes|
|From:||Adam Donald <Adam.Donald@xxxxxxxxxxxxxxx>|
|Date:||Tue, 30 Jun 2009 15:08:38 -0500|
|References:||<OF97A83ACB.604AE440-ON862575E4.00450F9F-862575E4.00475C94@xxxxxxxxx> <4A491887.8050509@xxxxxxxxxxx> <OFBF693EDC.C9829EF7-ON862575E4.006F5BEE-862575E4.00711ED9@xxxxxxxxx> <4A4927B9.7050304@xxxxxxxxxxx>|
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
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
> Thanks again for the input, I appreciate it!
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.
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
|<Prev in Thread]||Current Thread||[Next in Thread>|
|Previous by Date:||Re: Seg fault during xfs repair (segmentation fault / segv), Eric Sandeen|
|Next by Date:||Re: 2.6.30 panic - xfs_fs_destroy_inode, Patrick Schreurs|
|Previous by Thread:||Re: Correct usage of inode64/running out of inodes, Eric Sandeen|
|Next by Thread:||Re: A rescue tool: xfs_irecover, Jan Engelhardt|
|Indexes:||[Date] [Thread] [Top] [All Lists]|