linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Dmitry Monakhov <dmonakhov@openvz.org>
Cc: xfs@oss.sgi.com, linux-ext4@vger.kernel.org,
	linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] xfstests: test data integrity under disk failure
Date: Fri, 17 May 2013 09:31:53 +1000	[thread overview]
Message-ID: <20130516233153.GI24635@dastard> (raw)
In-Reply-To: <1368706052-24391-1-git-send-email-dmonakhov@openvz.org>

On Thu, May 16, 2013 at 04:07:32PM +0400, Dmitry Monakhov wrote:
> Parallels team have old good tool called hwflush-check which is server/client
> application for testing data integrity under system/disk failure conditions.
> Usually we run hwflush-check on two different hosts and use PMU to trigger real
> power failure of the client as a whole unit. This tests may be used for
> SSD checking (some of them are known to have probelms with hwflush).
> I hope it will be good to share it with community.
> 
> This tests simulate just one disk failure while client system should
> survive this failure. This test extend idea of shared/305.
> 1) Run hwflush-check server and client on same host as usual
> 2) Simulare disk failure via blkdev failt injection API aka 'make-it-fail'
> 3) Umount failed device
> 4) Makes disk operatable again
> 5) Mount filesystem
> 3) Check data integrity

So, for local disk failure, why do we need a client/server network
architecture? That just complicates the code, and AFAICT

all the client does is send report report packets to server which
contain an id number that is kept in memory. If on restart of the
client after failure the ID in the report packet doesn't match what
the server wants, then it fails the test.

So, why is the server needed here? Just dump the IDs the client
writes to the file on a device not being tested, and either diff
them against a golden image or run a check to see all the IDs are
monotonically increasing. That removes all the networking code from
the test, the need for a client/server architecture, etc, and makes
the test far easier to review.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

  reply	other threads:[~2013-05-16 23:31 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-16 12:07 [PATCH] xfstests: test data integrity under disk failure Dmitry Monakhov
2013-05-16 23:31 ` Dave Chinner [this message]
2013-05-18 12:13   ` Dmitry Monakhov
2013-05-19  1:32     ` 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=20130516233153.GI24635@dastard \
    --to=david@fromorbit.com \
    --cc=dmonakhov@openvz.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=xfs@oss.sgi.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).