From: Dave Chinner <david@fromorbit.com>
To: Brian Foster <bfoster@redhat.com>
Cc: Ben Myers <bpm@sgi.com>, Jan Kara <jack@suse.cz>, xfs@oss.sgi.com
Subject: Re: [PATCH] xfs: Don't flush inodes when project quota exceeded
Date: Thu, 22 Nov 2012 09:09:50 +1100 [thread overview]
Message-ID: <20121121220950.GR2591@dastard> (raw)
In-Reply-To: <50ACF289.2080901@redhat.com>
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...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2012-11-21 22:07 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-13 0:36 [PATCH] xfs: Don't flush inodes when project quota exceeded Jan Kara
2012-11-19 21:39 ` Jan Kara
2012-11-19 23:55 ` Dave Chinner
2012-11-20 0:04 ` Dave Chinner
2012-11-21 0:24 ` Jan Kara
2012-11-21 1:38 ` Dave Chinner
2012-11-21 1:44 ` Jan Kara
2012-11-20 16:15 ` Ben Myers
2012-11-20 17:03 ` Jan Kara
2012-11-20 20:20 ` Dave Chinner
2012-11-20 21:25 ` Brian Foster
2012-11-20 22:22 ` Dave Chinner
2012-11-21 15:26 ` Brian Foster
2012-11-21 22:09 ` Dave Chinner [this message]
2012-12-04 18:44 ` Ben Myers
2012-12-04 20:15 ` Dave Chinner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20121121220950.GR2591@dastard \
--to=david@fromorbit.com \
--cc=bfoster@redhat.com \
--cc=bpm@sgi.com \
--cc=jack@suse.cz \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox