From: Matthew Wilcox <matthew@wil.cx>
To: Wu Fengguang <fengguang.wu@intel.com>
Cc: Jan Kara <jack@suse.cz>, LKML <linux-kernel@vger.kernel.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Theodore Ts'o <tytso@mit.edu>,
Christoph Hellwig <hch@infradead.org>
Subject: Re: [PATCH] fs: Make write(2) interruptible by a fatal signal
Date: Thu, 1 Dec 2011 07:27:05 -0700 [thread overview]
Message-ID: <20111201142704.GT4387@parisc-linux.org> (raw)
In-Reply-To: <20111201122425.GA16274@localhost>
On Thu, Dec 01, 2011 at 08:24:25PM +0800, Wu Fengguang wrote:
> > This patch makes write interruptible by SIGKILL.
>
> Let me try to summarize the objective impacts of (not) merging this
> patch, and would like to hear more opinions from experienced users.
>
> - w/o patch
>
> BEHAVIOR:
> write(2) insists to complete even when the user really wants to stop it.
>
> IMPACT:
> It could be annoying to experience slow responses to "kill -9" when
> it's a large write to a slow device, for example,
>
> dd if=/dev/zero of=/mnt/nokia/zero bs=100M
Another problem scenario is an NFS mounted file going away while the
user is writing to it. The user should be able to kill the stuck process
without rebooting their machine.
> - w/ patch
>
> BEHAVIOR:
> write(2) aborts quickly with possible partial write on SIGKILL
>
> IMPACT:
> The partial write might lead to data corruption somewhere, sometime
> (the possibility is low but real) and bring trouble to some users.
Let's examine these cases. We've already written at least some of the
data into the page cache (and updated i_size for extending writes in the
call to ->write_end). It's just not hit the backing store yet. That means
that this state of affairs is already *visible* to another process on the
same machine, it's just not *durable* (eg in the event of power failure).
I think in the worst case, we've simply extended the window of opportunity
for another process to see the partial write.
So, please add
Acked-by: Matthew Wilcox <matthew.r.wilcox@intel.com>
--
Matthew Wilcox Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
next prev parent reply other threads:[~2011-12-01 14:27 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-01 10:27 [PATCH] fs: Make write(2) interruptible by a fatal signal Jan Kara
2011-12-01 12:24 ` Wu Fengguang
2011-12-01 14:27 ` Matthew Wilcox [this message]
2011-12-01 16:10 ` Linus Torvalds
2011-12-02 11:58 ` Janne Blomqvist
2011-12-02 2:05 ` Wu Fengguang
2011-12-02 6:36 ` [PATCH] writeback: permit through good bdi even when global dirty exceeded Wu Fengguang
2011-12-02 7:03 ` Andrew Morton
2011-12-02 8:29 ` Wu Fengguang
2011-12-02 10:16 ` Wu Fengguang
2011-12-02 10:28 ` Wu Fengguang
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=20111201142704.GT4387@parisc-linux.org \
--to=matthew@wil.cx \
--cc=akpm@linux-foundation.org \
--cc=fengguang.wu@intel.com \
--cc=hch@infradead.org \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=tytso@mit.edu \
/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;
as well as URLs for NNTP newsgroup(s).