Hi Neil,
On Mon, Mar 21, 2011 at 10:04:57PM +1100, NeilBrown wrote:
> On Mon, 21 Mar 2011 11:40:07 +0100 Piergiorgio Sartor
> <piergiorgio.sartor@xxxxxxxx> wrote:
>
>
> > > I have applied this patch to me git now - with some minor changes.
> >
> > Thanks.
> >
> > One question, I did not find the previous patch to "restripe.c",
> > which was adding the ":offset" capability. This was in order to
> > be able to cope with metadata 1.1 or 1.2 (offset to be determined).
>
> I cannot seem to find it. Please resend.
neither me, maybe I just forgot to send it.
Anyway, here below is the patch:
--- cut here ---
diff -urN a/restripe.c b/restripe.c
--- a/restripe.c 2011-02-18 23:18:20.377740868 +0100
+++ b/restripe.c 2011-02-18 23:30:07.589841525 +0100
@@ -875,6 +875,14 @@
exit(3);
}
for (i=0; i<raid_disks; i++) {
+ char *p;
+ p = strchr(argv[9+i], ':');
+
+ if(p != NULL) {
+ *p++ = '\0';
+ offsets[i] = atoll(p) * 512;
+ }
+
fds[i] = open(argv[9+i], O_RDWR);
if (fds[i] < 0) {
perror(argv[9+i]);
--- cut here ---
Thanks,
bye,
pg
>
> >
> > > > Other item is that due to "sysfs.c" linking (see below) the
> > > > "Makefile" needed some changes, I hope this is not a problem.
> > >
> > > I have reverted most of these changes and the linking with sysfs.c isn't
> > > needed yet. When it is we can sort out how best to achieve it.
> > >
> > > >
> > > > Next steps (TODO list you like) would be:
> > > >
> > > > 1) Add the "sysfs.c" code in order to retrieve the HDDs info
> > > > from the MD device. It is already linked, together with the
> > > > whole (mdadm) universe, since it seems it cannot leave alone.
> > > > I'll need some advice or hint on how to do use it. I checked
> > > > "sysfs.c", but before I dig deep into it maybe better to
> > > > have some advice (maybe just one function call will do it).
> > >
> > > What exactly do you want to achieve?
> > >
> > > I suspect you want to a open the md device, then
> > >
> > > info = sysfs_read(fd, -1,
> > > GET_LEVEL|GET_LAYOUT_GET_DISKS|GET_CHUNK|GET_DEVS|GET_OFFSET);
> > >
> > > (possibly with other flags) and then extract the info you want from the data
> > > structure returned - but I'm only guessing at what you might want.
> >
> > I think this more or less correct.
> >
> > I would like to pass, to "raid6check", the md device as only
> > parameter, maybe with some start/stop position, and derive all
> > the needed information from that.
> >
> > That is, it should be: raid6check /dev/mdX start stop
> > Or, possibly: raid6check /dev/mdX start length
> > Or just: raid6check /dev/mdX
> >
> > This means, the information that should be derived is:
> >
> > 1) level, in order to confirm it is 6
> > 2) layout
> > 3) disk components
> > 4) offset for each component
> > 5) chunk size
> >
> > That should be all, I guess.
> >
> > Your "sysfs_read" seems to do exactly this, please confirm.
>
> Yes, all that should be in there - experiment and see if you get what you
> expect!
>
> >
> > > >
> > > > 2) Add the suspend lo/hi control. Fellow John Robinson was
> > > > suggesting to look into "Grow.c", which I did, but I guess
> > > > the same story as 1) is valid: better to have some hint on
> > > > where to look before wasting time.
> > >
> > > This would be:
> > >
> > > sysfs_set_num(info, NULL, "suspend_lo", offset*data_disks);
> > > sysfs_set_num(info, NULL, "suspend_hi", (offset+chunksize)*data_disks);
> > >
> > > to freeze one stripe. Then work in there.
> > > The addresses are addresses in the array, hence the multiplication
> > > by data_disks (which is raid_disks - 2 for RAID6).
> > >
> > > Don't hold the array suspended for too long or something might get
> > > upset. And allocate any memory you need first, and call
> > > mlockall(MCL_CURRENT | MCL_FUTURE);
> > >
> > > first to be even more safe.
> >
> > Thanks for the explanation. How is, then, the "unfreeze"?
> > Just writing (0) to both hi and lo?
>
> Just make sure lo >= hi and it will unfreeze.
> Some kernels are a bit fussy about the order of writing to these.
> So if you just write a big number to 'lo', then the same to 'hi', you should
> be safe.
>
>
> 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
--
piergiorgio
--
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
