From: NeilBrown <neilb@suse.de>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: Christoph Hellwig <hch@infradead.org>,
axboe@kernel.dk, lucho@ionkov.net, jack@suse.cz,
ericvh@gmail.com, tytso@mit.edu, rminnich@sandia.gov,
viro@zeniv.linux.org.uk, martin.petersen@oracle.com,
david@fromorbit.com, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org, adilger.kernel@dilger.ca,
bharrosh@panasas.com, jlayton@samba.org,
v9fs-developer@lists.sourceforge.net, linux-ext4@vger.kernel.org
Subject: Re: [PATCH 1/4] bdi: Track users that require stable page writes
Date: Thu, 22 Nov 2012 09:06:43 +1100 [thread overview]
Message-ID: <20121122090643.7c9551dc@notabene.brown> (raw)
In-Reply-To: <20121121215207.GB32202@blackbox.djwong.org>
[-- Attachment #1: Type: text/plain, Size: 1228 bytes --]
On Wed, 21 Nov 2012 13:52:07 -0800 "Darrick J. Wong"
<darrick.wong@oracle.com> wrote:
> > Can you add a rationale on why we'd want to allow users to change the
> > value? I can't really think of any.
>
> I dislike the idea that if a program is dirtying pages that are being written
> out, then I don't really know whether the disk will write the before or after
> version. If the power goes out before the inevitable second write, how do you
> know which version you get? Sure would be nice if I could force on stable
> writes if I'm feeling paranoid.
I don't think this fear is at all rational (but then you did suggest
paranoia).
If the power goes out, then any write that has been requested, but for which
an 'fsync' hasn't completed, may - or may not - have been written. Setting
this flag doesn't really change that.
The filesystem should provide some degree of certainty - i.e. either old
data or new data and I believe they mostly do - though ext3 with
journal=writeback explicitly doesn't promise very much. Beyond that, if you
want any certainty then the app must provide that by using fsync.
So I'm with Christoph here: I don't think the flag should be user-settable.
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
next prev parent reply other threads:[~2012-11-21 22:06 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-21 2:00 [PATCH v2.1 0/3] mm/fs: Implement faster stable page writes on filesystems Darrick J. Wong
2012-11-21 2:00 ` [PATCH 1/4] bdi: Track users that require stable page writes Darrick J. Wong
2012-11-21 7:54 ` Christoph Hellwig
2012-11-21 10:52 ` Christoph Hellwig
2012-11-21 10:56 ` Christoph Hellwig
2012-11-21 21:52 ` Darrick J. Wong
2012-11-21 22:06 ` NeilBrown [this message]
2012-11-22 2:33 ` [PATCH] " Darrick J. Wong
2012-11-22 7:08 ` Christoph Hellwig
2012-11-21 2:00 ` [PATCH 2/4] mm: Only enforce stable page writes if the backing device requires it Darrick J. Wong
2012-11-21 10:57 ` Christoph Hellwig
2012-11-21 2:00 ` [PATCH 3/4] 9pfs: Fix filesystem to wait for stable page writeback Darrick J. Wong
2012-11-21 2:00 ` [PATCH 4/4] ext3: Warn if mounting rw on a disk requiring stable page writes Darrick J. Wong
2012-11-21 2:15 ` Jan Kara
2012-11-21 21:13 ` Darrick J. Wong
2012-11-21 21:33 ` Jan Kara
2012-11-21 21:47 ` NeilBrown
2012-11-22 1:47 ` Darrick J. Wong
2012-11-22 2:36 ` [RFC PATCH 1/2] mm: Introduce page flag to indicate stable page status Darrick J. Wong
2012-11-22 2:36 ` [RFC PATCH 2/2] jbd: Stabilize pages during writes when in ordered mode Darrick J. Wong
2012-11-22 9:19 ` Jan Kara
2012-11-22 9:12 ` [PATCH 4/4] ext3: Warn if mounting rw on a disk requiring stable page writes Jan Kara
2012-11-27 2:17 ` Darrick J. Wong
2012-12-05 12:12 ` Jan Kara
2012-12-08 1:09 ` Darrick J. Wong
2012-12-10 10:41 ` Jan Kara
2012-11-22 23: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=20121122090643.7c9551dc@notabene.brown \
--to=neilb@suse.de \
--cc=adilger.kernel@dilger.ca \
--cc=axboe@kernel.dk \
--cc=bharrosh@panasas.com \
--cc=darrick.wong@oracle.com \
--cc=david@fromorbit.com \
--cc=ericvh@gmail.com \
--cc=hch@infradead.org \
--cc=jack@suse.cz \
--cc=jlayton@samba.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lucho@ionkov.net \
--cc=martin.petersen@oracle.com \
--cc=rminnich@sandia.gov \
--cc=tytso@mit.edu \
--cc=v9fs-developer@lists.sourceforge.net \
--cc=viro@zeniv.linux.org.uk \
/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).