All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ric Wheeler <rwheeler@redhat.com>
To: Greg Freemyer <greg.freemyer@gmail.com>
Cc: Chris Green <cgreen@valvesoftware.com>,
	Neil Brown <neilb@suse.de>,
	"linux-raid@vger.kernel.org" <linux-raid@vger.kernel.org>,
	Mike Snitzer <snitzer@redhat.com>,
	Tom Coughlan <coughlan@redhat.com>,
	Chris Mason <chris.mason@oracle.com>
Subject: Re: [PATCH] barrier support for other md/raid levels
Date: Fri, 18 Sep 2009 14:43:20 -0400	[thread overview]
Message-ID: <4AB3D4C8.1080602@redhat.com> (raw)
In-Reply-To: <87f94c370909181138g197be2fegd4032778ca6d3351@mail.gmail.com>

On 09/18/2009 02:38 PM, Greg Freemyer wrote:
> On Fri, Sep 18, 2009 at 2:28 PM, Ric Wheeler<rwheeler@redhat.com>  wrote:
>    
>> On 09/18/2009 02:19 PM, Chris Green wrote:
>>      
>>> It seems like what you'd need to robustly test barriers is some sort of
>>> barrier-supporting loopback device, which
>>> acted correctly with barriers, but had worst-case behavior without them
>>> (buffering things for random arbitrarily long periods of time,
>>> performing all operations in random order, etc).
>>>
>>>
>>>
>>>        
>> I think that it is pretty easy to get corruption (defined as fsck issues) if
>> we have non-working barriers and do power fail testing. It is a bit tricky
>> to automate that though but we are working on it,
>>
>> ric
>>      
> Ric,
>
> You are probably already using them to help automate the process, but
> if you don't know computer controlled power switches are pretty
> standard fare for computer clusters.  I'm sure Redhat's cluster team
> has some.
>
> And the cluster team may also have scripts to test things like
> unexpected power fails to one of the cluster members.  It may not be
> too hard to adjust those scripts to handle your needs.
>
> Greg
>    

We definitely have those and do similar testing. It is a matter of 
getting a good work load and automating the regression testing.

Chris's earlier test is a great starting point, HP has tests (hazard) 
that do really mean things to storage as well.

Just need to get time to get it all going :-)

ric


  reply	other threads:[~2009-09-18 18:43 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-18  6:21 [PATCH] barrier support for other md/raid levels Neil Brown
2009-09-18 11:44 ` Ric Wheeler
2009-09-18 18:19   ` Chris Green
2009-09-18 18:28     ` Ric Wheeler
2009-09-18 18:38       ` Greg Freemyer
2009-09-18 18:43         ` Ric Wheeler [this message]
2009-09-18 20:18           ` Majed B.
2009-09-20 21:48             ` Clinton Lee Taylor
2009-09-20 22:57               ` Neil Brown
  -- strict thread matches above, loose matches on Subject: below --
2009-09-19  8:58 Michael Guntsche

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=4AB3D4C8.1080602@redhat.com \
    --to=rwheeler@redhat.com \
    --cc=cgreen@valvesoftware.com \
    --cc=chris.mason@oracle.com \
    --cc=coughlan@redhat.com \
    --cc=greg.freemyer@gmail.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=neilb@suse.de \
    --cc=snitzer@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.