[Top] [All Lists]

Re: xfs_repair: "fatal error -- ran out of disk space!"

To: Eric Sandeen <sandeen@xxxxxxxxxxx>
Subject: Re: xfs_repair: "fatal error -- ran out of disk space!"
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Thu, 23 Jun 2011 09:24:18 +1000
Cc: "Patrick J. LoPresti" <lopresti@xxxxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <4E026C42.2030500@xxxxxxxxxxx>
References: <BANLkTi=gS5iO9R9pVk_df-4ofkkb0ZJgfw@xxxxxxxxxxxxxx> <4E026C42.2030500@xxxxxxxxxxx>
User-agent: Mutt/1.5.20 (2009-06-14)
On Wed, Jun 22, 2011 at 05:27:14PM -0500, Eric Sandeen wrote:
> On 6/22/11 4:32 PM, Patrick J. LoPresti wrote:
> > I have a 5.1TB XFS file system that is 93% full (399G free according to 
> > "df").
> > 
> > I am trying to run "xfs_repair" on it.
> > 
> > The output is appended.
> > 
> > Question:  What am I supposed to do about this?  "xfs_repair -V" says
> > "xfs_repair version 3.1.5".  (I downloaded and built the latest
> > version hoping it would fix the issue, but no luck.)  Should I just
> > start deleting files at random?
> You could start by removing a few files you know you don't need, rather than
> at random.  :)
> TBH I've not seen this one before, and the error message is not all that
> helpful.  It'd be nice to know how many blocks it was trying to reserve
> when it ran out of space; I guess you'd need to use gdb, or instrument
> all the calls to res_failed() in phase6.c to know for sure...

Also, the number of inodes and directories in your filesystem might
tell us whether we should expect an ENOSPC, as well. I suspect that
there's an accounting error, because 400GB of transaction
reservations is an awful lot of directory rebuilds....


Dave Chinner

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