On Tue, 1 Feb 2011 20:21:54 +0100 Piergiorgio Sartor <piergiorgio.sartor@xxxxxxxx> 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@xxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
