| To: | Jan Kara <jack@xxxxxxx> |
|---|---|
| Subject: | Re: [PATCH 0/2] Improve writeout pattern from xfs_flush_pages() |
| From: | Christoph Hellwig <hch@xxxxxxxxxxxxx> |
| Date: | Thu, 4 Aug 2011 08:19:16 -0400 |
| Cc: | Christoph Hellwig <hch@xxxxxxxxxxxxx>, xfs@xxxxxxxxxxx, linux-fsdevel@xxxxxxxxxxxxxxx |
| In-reply-to: | <20110804120724.GA20800@xxxxxxxxxxxxx> |
| References: | <1312404545-15400-1-git-send-email-jack@xxxxxxx> <20110803214206.GA20477@xxxxxxxxxxxxx> <20110804103616.GF17196@xxxxxxxxxxxxx> <20110804104210.GA30823@xxxxxxxxxxxxx> <20110804120724.GA20800@xxxxxxxxxxxxx> |
| User-agent: | Mutt/1.5.21 (2010-09-15) |
On Thu, Aug 04, 2011 at 02:07:24PM +0200, Jan Kara wrote:
> Hmm, BTW, shouldn't the call to xfs_flush_pages() in
> xfs_file_buffered_aio_write() be converted to an asynchronous one? I don't
> quite see a point in waiting for io completion... Generally, flushing of
> the inode there seems of limited usefulness to me since that inode could be
> just a tiny victim not holding much delayallocated blocks.
This comes from commit
xfs: make inode flush at ENOSPC synchronous
from Dave - before that it was asynchronous and in weird context, so
it seems we defintively need it to be synchronous. I agree that just
flushing this inode seems like a rather odd handling for ENOSPC. It's
even more odd as we already use the big hammer before in when we
git ENOSPC in ->write_begin. The only thing I can imagine is that
this is the last attempt to get anything freed.
|
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [PATCH 0/2] Improve writeout pattern from xfs_flush_pages(), Jan Kara |
|---|---|
| Next by Date: | Re: [PATCH 4/4] xfsdump: convert to the POSIX signal API, Bill Kendall |
| Previous by Thread: | Re: [PATCH 0/2] Improve writeout pattern from xfs_flush_pages(), Jan Kara |
| Next by Thread: | Re: [PATCH 0/2] Improve writeout pattern from xfs_flush_pages(), Jan Kara |
| Indexes: | [Date] [Thread] [Top] [All Lists] |