linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jamie Lokier <jamie@shareable.org>
To: Ric Wheeler <rwheeler@redhat.com>
Cc: Michael Rubin <mrubin@google.com>,
	Chris Worley <worleys@gmail.com>, 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: Thu, 2 Jul 2009 03:12:19 +0100	[thread overview]
Message-ID: <20090702021219.GA18372@shareable.org> (raw)
In-Reply-To: <4A4BAEA2.6000101@redhat.com>

Ric Wheeler wrote:
> One way to test this with reasonable, commodity hardware would be 
> something like the following:
> 
> (1) Get an automated power kill setup to control your server

etc.  Good plan.

Another way to test the entire software stack, but not the physical
disks, is to run the entire test using VMs, and simulate hard disk
write caching and simulated power failure in the VM.  KVM would be a
great candidate for that, as it runs VMs as ordinary processes and the
disk I/O emulation is quite easy to modify.

As most issues probably are software issues (kernel, filesystems, apps
not calling fsync, or assuming barrierless O_DIRECT/O_DSYNC are
sufficient, network fileserver protocols, etc.), it's surely worth a look.

It could be much faster than the physical version too, in other words
more complete testing of the software stack given available resources.

With the ability to "fork" a running VM's state by snapshotting it and
continuing, it would even be possible to simulate power failure cache
loss scenarios at many points in the middle of a stress test, with the
stress test continuing to run - no full reboot needed at every point.
That way, maybe deliberate trace points could be placed in the
software stack at places where power failure cache loss seems likely
to cause a problem.

-- Jamie

  parent reply	other threads:[~2009-07-02  2:12 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
2009-07-01 18:44     ` Ric Wheeler
2009-07-01 19:58       ` Jeff Moyer
2009-07-02  2:12       ` Jamie Lokier [this message]
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=20090702021219.GA18372@shareable.org \
    --to=jamie@shareable.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=mrubin@google.com \
    --cc=rwheeler@redhat.com \
    --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).