On Tue, Dec 04, 2012 at 12:44:59PM -0600, Ben Myers wrote: > Hey Dave, > > On Thu, Nov 22, 2012 at 09:09:50AM +1100, Dave Chinner wrote: > > On Wed, Nov 21, 2012 at 10:26:01AM -0500, Brian Foster wrote: > > > On 11/20/2012 05:22 PM, Dave Chinner wrote: > > > > On Tue, Nov 20, 2012 at 04:25:34PM -0500, Brian Foster wrote: > > > >> 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. > > > > Possibly, though we can also have dirty inodes that don't have > > speculative prealloc (e.g. hole filling writes) and we really need to > > flush them at ENOSPC, too. In general, I think the real ENOSPC case > > needs the big hammer because we have to reclaim every last piece of > > unnecessary reservation as possible to allow anything to proceed. > > Porject quota ENOSPC isn't such a problem here, as there's still > > other free space in the filesystem that allow normal operation to > > take place... > > Tossing away all of our remedial action in the project quota ENOSPC case to > work around an nfs client issue strikes me as the wrong thing to do. I doesn't > look like this is what you're suggesting but I just want to see if we're on the > same page. It's not a NFS client issue - it's an NFS server issue. i.e. the server is the one telling the client that it has no space, so the server has to take appropriate action. i.e. the remedial action needs to stay. > It seems to me that project quota ENOSPC has basically the same issues as with > the real ENOSPC case, but it only needs to be targeted at inodes that affect > the quota in question. The flush and trimming should still be done, otherwise > once project quota ENOSPC is hit there is no way for the nfs client to clear up > the situation... we just need to target only inodes that affect the quota where we > hit limits instead of all inodes. Effectively - the trimming of speculative delalloc is really the main thing as the metadata reservation for delalloc is generally not noticable for situations where project quotas are typically used. This targeted speculative prealloc trimming is exactly what we've been talking about.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
