From: Michael Rubin <mrubin@google.com>
To: Chris Worley <worleys@gmail.com>
Cc: Shaozhi Ye <yeshao@google.com>,
linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org
Subject: Re: Plans to evaluate the reliability and integrity of ext4 against power failures.
Date: Wed, 1 Jul 2009 11:31:12 -0700 [thread overview]
Message-ID: <532480950907011131o7e9fc8bdn64002f130cc9615d@mail.gmail.com> (raw)
In-Reply-To: <f3177b9e0907011107q17507be5icae2c1105faf4800@mail.gmail.com>
On Wed, Jul 1, 2009 at 11:07 AM, Chris Worley<worleys@gmail.com> wrote:
> On Tue, Jun 30, 2009 at 5:27 PM, Shaozhi Ye<yeshao@google.com> wrote:
> This looks like a very valuable project. I do lack understanding of
> how certain problems that very much need to be tested will be tested.
> From your pdf:
>
> "Data loss: The client thinks the server has A while the server
> does not."
>
> I've been wondering how you test to assure that data committed to the
> disk is really committed?
What we are trying to capture is what the users perceives and can
expect in our environment. This is not an attempt to know the moment
the OS can guarantee the data is stored persistently. I am not sure if
that's feasible to do with write caching drives today.
This experiment's goal as of now is not to know the exact moment in
time "when the data is committed". It has two goals. The first to
assure ourselves there is no strange corner case making ext4 behave
worse or unexpectedly compared to ext2 in the rare event of a power
failure. And to deliver expectations to our users on the
recoverability of data after the event.
For now we are employing a client server model for network exported
sharing in this test. In that context the App doesn't have a lot of
methods to know when the data is committed. I know of O_DIRECT, fsync,
etc. Given these current day interfaces what can the network client
apps expect?
After we have results we will try to figure out if we need to develop
new interfaces or methods to improve the situation and hopefully start
sending patches.
> I just don't see a method to test this, but it is so critically important.
I agree.
mrubin
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2009-07-01 18:31 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-30 23:27 Plans to evaluate the reliability and integrity of ext4 against power failures Shaozhi Ye
2009-07-01 0:58 ` Eric Sandeen
2009-07-01 17:39 ` Michael Rubin
2009-07-01 18:07 ` Chris Worley
2009-07-01 18:31 ` Michael Rubin [this message]
2009-07-01 18:44 ` Ric Wheeler
2009-07-01 19:58 ` Jeff Moyer
2009-07-02 2:12 ` Jamie Lokier
2009-07-02 11:21 ` Ric Wheeler
2009-07-01 20:59 ` Theodore Tso
2009-07-02 1:04 ` Michael Rubin
2009-07-01 23:37 ` Andreas Dilger
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=532480950907011131o7e9fc8bdn64002f130cc9615d@mail.gmail.com \
--to=mrubin@google.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=worleys@gmail.com \
--cc=yeshao@google.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;
as well as URLs for NNTP newsgroup(s).