xfs
[Top] [All Lists]

Re: Review: Be smarter about handling ENOSPC during writeback

To: David Chinner <dgc@xxxxxxx>
Subject: Re: Review: Be smarter about handling ENOSPC during writeback
From: Nathan Scott <nscott@xxxxxxxxxx>
Date: Tue, 12 Jun 2007 09:13:45 +1000
Cc: Timothy Shimmin <tes@xxxxxxx>, xfs-dev <xfs-dev@xxxxxxx>, xfs-oss <xfs@xxxxxxxxxxx>
In-reply-to: <20070608073342.GW85884050@xxxxxxx>
Organization: Aconex
References: <20070604045219.GG86004887@xxxxxxx> <E436D9833B42EFAE6C2CE987@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <F80A059A828DE0E57A655471@xxxxxxxxxxxxxxxxxxxxxxx> <20070608073342.GW85884050@xxxxxxx>
Reply-to: nscott@xxxxxxxxxx
Sender: xfs-bounce@xxxxxxxxxxx
On Fri, 2007-06-08 at 17:33 +1000, David Chinner wrote:
> On Fri, Jun 08, 2007 at 03:28:14PM +1000, Timothy Shimmin wrote:

> > Will we get questions from people about reduced space from df? :)
> 
> If we do, I think you just volunteered to write the FAQ entry ;)

It would be more correct of XFS to start doing the right thing by
reporting different values for b_free and b_avail in statfs(2) -
this code in xfs_mount.c::xfs_statvfs() ...

    statp->f_bfree = statp->f_bavail =
                            sbp->sb_fdblocks - XFS_ALLOC_SET_ASIDE(mp);

I know this wasn't done for the original per-mount space reserving
ioctls (that was for one user though - dmapi, so I can see why there
may have been a shortcut done there) ... but if it affects everyone
now, there will be questions asked, and there is a standard interface
for reporting this space discrepency that tools like df(1) already
use.

cheers.



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