[Top] [All Lists]

Re: Correct usage of inode64/running out of inodes

To: Adam Donald <Adam.Donald@xxxxxxxxxxxxxxx>
Subject: Re: Correct usage of inode64/running out of inodes
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Mon, 29 Jun 2009 15:44:41 -0500
Cc: xfs@xxxxxxxxxxx
In-reply-to: <OFBF693EDC.C9829EF7-ON862575E4.006F5BEE-862575E4.00711ED9@xxxxxxxxx>
References: <OF97A83ACB.604AE440-ON862575E4.00450F9F-862575E4.00475C94@xxxxxxxxx> <4A491887.8050509@xxxxxxxxxxx> <OFBF693EDC.C9829EF7-ON862575E4.006F5BEE-862575E4.00711ED9@xxxxxxxxx>
User-agent: Thunderbird (Macintosh/20090605)
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


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

<Prev in Thread] Current Thread [Next in Thread>