From: NeilBrown <neilb@suse.de>
To: Piergiorgio Sartor <piergiorgio.sartor@nexgo.de>
Cc: linux-raid@vger.kernel.org
Subject: Re: User space RAID-6 access
Date: Wed, 2 Feb 2011 07:18:50 +1100 [thread overview]
Message-ID: <20110202071850.3b671c1e@notabene.brown> (raw)
In-Reply-To: <20110201192154.GA2696@lazy.lzy>
On Tue, 1 Feb 2011 20:21:54 +0100 Piergiorgio Sartor
<piergiorgio.sartor@nexgo.de> wrote:
> On Tue, Feb 01, 2011 at 07:52:59AM +1100, NeilBrown wrote:
> > On Mon, 31 Jan 2011 21:20:55 +0100 Piergiorgio Sartor
> > <piergiorgio.sartor@nexgo.de> wrote:
> >
> > > Hi all,
> > >
> > > some times ago, I think was Neil, it was mentioned
> > > about the possibility to access consistently a RAID-6
> > > array from user space, in order to be able to perform
> > > some checks, like the notorius "which HDD has wrong data".
> > >
> > > Is there any reference or documentation or source code
> > > which can be taken as example for such a case?
> > >
> >
> > Look in the mdadm source code, particularly at restripe.c
> >
> > Also
> > make test_stripe
> >
> > make a program the the test suite uses for verify data correctness.
> >
> > That should give you enough hints to get you started.
>
>
> Hi Neil, thanks for the pointer.
>
> I had a look at the code and there is something I did not get.
>
> It seems to me the HDDs composing the array are "simply"
> opened with "open".
>
> In case the array is in use, how is avoided a race condition
> between the "test_stripe" program and the md device?
>
> I mean, the first could start to read from the HDDs and the
> other could write something in the same place, leading to an
> inconsistent parity, from the "test_stripe" point of view,
> since it missed some update.
>
> Or there is a locking inside md (in "test_stripe" I could
> not see and it would also be dangerous)?
>
> Thanks again,
>
> bye,
>
I didn't realise that you wanted to look at the members of the array while
the array was active!! That is a bit harder. But not impossible.
If you write a couple of numbers to 'suspend_lo' and 'suspend_hi' in sysfs,
then writes to blocks between those two array addresses will be blocked.
So you could suspend a region, look at the blocks, then un-suspend.
NeilBrown
next prev parent reply other threads:[~2011-02-01 20:18 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-31 20:20 User space RAID-6 access Piergiorgio Sartor
2011-01-31 20:52 ` NeilBrown
2011-02-01 19:21 ` Piergiorgio Sartor
2011-02-01 20:14 ` John Robinson
2011-02-01 20:18 ` NeilBrown [this message]
2011-02-01 21:00 ` Piergiorgio Sartor
2011-02-05 17:33 ` Piergiorgio Sartor
2011-02-05 20:58 ` NeilBrown
2011-02-07 22:24 ` [PATCH] " Piergiorgio Sartor
2011-02-07 22:49 ` NeilBrown
2011-02-09 18:47 ` Piergiorgio Sartor
2011-02-17 6:23 ` NeilBrown
2011-02-17 20:01 ` Piergiorgio Sartor
2011-02-18 23:02 ` Piergiorgio Sartor
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=20110202071850.3b671c1e@notabene.brown \
--to=neilb@suse.de \
--cc=linux-raid@vger.kernel.org \
--cc=piergiorgio.sartor@nexgo.de \
/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).