Re: [PATCH] xfs: Don't flush inodes when project quota exceeded

[Brian Foster <bfoster@redhat.com>]

On 11/20/2012 05:22 PM, Dave Chinner wrote:
> On Tue, Nov 20, 2012 at 04:25:34PM -0500, Brian Foster wrote:
>> On 11/20/2012 03:20 PM, Dave Chinner wrote:
...
>>> It's by design. Directory tree quota is used as a method of
>>> exporting multiple sub-dirs from a single filesystem but having them
>>> appear to NFS clients just like a standalone filesystem. Hence when
>>> you run out of projet quota, it is treated like an ENOSPC condition
>>> for the directory sub-tree - it flushes as much of the metadata
>>> reservations out as possible to maximise the data space for the
>>> directory tree.
> 
> And FWIW, returning ENOSPC to the NFS client inthese situations is
> the correct error to be returning as they know nothing about the
> fact that project quotas are used on the server to limit the size of
> the export the client has mounted.
> 

Ok, I initially missed that we returned ENOSPC in the project quota
situation, so I might have mixed up what I was referring to as EDQUOT
vs. ENOSPC. I see the XFS_QMOPT_ENOSPC logic that appears to cause that
behavior.

>>> For user/group quotas, this requirement of behaving like a
>>> standalone filesystem does not exist, and so when you EDQUOT a
>>> user/group there is no need to reclaim metadata reservations to make
>>> more data space available....
>>
>> ... but the metadata reservation issue discussed here sounds like it
>> could still be a problem. Is the implication that we could still do a
>> project quota filtered eofblocks scan, but it must also (or instead, if
>> a flush implies trimming post-eof space) include an inode flush in the
>> project quota case?
> 
> It's never been reported as a problem. In the absence of problems
> being reported over the past 10+ years, I don't think we should be
> changing the behaviour of inode flushing at EDQUOT. Trimming
> speculative prealloc, yes, but I don't think flushing inodes is
> necessary.
> 

I was unclear. By problem, I just meant that replacing the inode flush
after a project quota ENOSPC with an eofblocks scan would be a problem
(e.g., a flush + eofblocks trim is the right approach, as you outline
below).

>> Otherwise, unless I'm mistaken it sounds like we can use the existing
>> eofblocks scan on user/group EDQUOT situations.
> 
> That we can. And for the project case, it's a simply and extra flag
> and a call to filemap_flush() to do an async writeback before
> trimming the specualtive preallocation.
> 

This makes sense generally. I'll need to dig further into this code to
wrap my head around it. If my current understanding is correct, it
sounds like we could do the same thing in general, non-quota ENOSPC
handling, right? E.g., an unfiltered eofblocks scan (plus the flush bit)
followed by a retry, rather than a complete flush of all dirty inodes.

Brian

...
> 
> Cheers,
> 
> Dave.
> 

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs