When no output file is given save_stripes() should collect amount of stripes
in passed buffer. Currently all stripes are saved in the same area in passed
buffer. This causes that last stripe is returned on buffer begin only.
Increase buffer (buf) pointer when save_stripes() is about switch to next
stripe operation. This allows for proper buffer filling as input parameter
length directs.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: Krzysztof Wojcik <krzysztof.wojcik@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
For external metadata backup location and saving methods depends
on metadata specific implementation details. Currently restore_stripes()
function is able to restore data only from the given backup file handles
and it is used only for assembling partially reshaped arrays.
As this function will be very helpful for external metadata backup
mechanism, add the support for restoring data from the given source buffer.
Add possibility for save_stripes() to work without designation targets.
Save_stripes() can now prepare data for restore_stripes() only.
Signed-off-by: Maciej Trela <maciej.trela@intel.com>
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: Krzysztof Wojcik <krzysztof.wojcik@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
If restripe is called to restore stripes of one size and then
save stripes with a larger chunk size, the 'zero' buffer will not
be large enough and a double-degraded RAID6 will over-run the buffer.
So record the current size of the zero buffer and use it when deciding
if we need to allocate a new buffer.
Reported-by: Brad Campbell <lists2009@fnarfbargle.com>
Signed-off-by: NeilBrown <neilb@suse.de>
If device name ends :number, e.g.
/dev/sda0:1234
then assume the RAID data starts that many sectors from start of
device.
Signed-off-by: NeilBrown <neilb@suse.de>
Hi Neil,
please find attached a patch, to mdadm-3.2 base, including
a standalone versione of the raid-6 check.
This is basically a re-working (and hopefully improvement)
of the already implemented check in "restripe.c".
I splitted the check function into "collect" and "stats",
so that the second one could be easily replaced.
The API is also simplified.
The command line option are reduced, since we only level
is raid-6, but the ":offset" option is included.
The output reports the block/stripe rotation, P/Q errors
and the possible HDD (or unknown).
BTW, the patch applies also to the already patched "restripe.c",
including the last ":offset" patch (which is not yet in git).
Other item is that due to "sysfs.c" linking (see below) the
"Makefile" needed some changes, I hope this is not a problem.
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).
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.
3) Add a repair option (future). This should have different
levels, like "all", "disk", "stripe". That is, fix everything
(more or less like "repair"), fix only if a disk is clearly
having problems, fix each stripe which has clearly a problem
(but maybe different stripes may belong to different HDDs).
So, for the point 1) and 2) would be nice to have some more
detail on where to look what. Point 3) we will discuss later.
Thanks, please consider for inclusion,
bye,
pg
Signed-off-by: NeilBrown <neilb@suse.de>
> I have applied some patch - with some formatting changes to make it consistent
> with the rest of the code.
>
> I don't really have time to look more deeply at it at the moment.
> Maybe someone else will?...
Hi Neil,
thanks for including this in git.
Actually I did it look at it :-) and I already found a
couple of issues, below is a small fix patch.
Signed-off-by: NeilBrown <neilb@suse.de>
> test_stripe assumes that the data starts at the start of each device.
> AS you are using 1.2 metadata (the default), data starts about 1M in to
> the device (I think - you can check with --examine)
>
> You could fix test_stripe to put the right value in the 'offsets' array,
> or you could create the array with 1.0 or 0.90 metadata.
Hi Neil,
thanks for the info, maybe this should be a second patch.
In the meantime, please find attached a patch to restripe.c
of mdadm 3.2 (latest, I hope).
This should add the functionality to detect, in RAID-6,
which of the disks potentially has problems, in case of
parity errors.
Some checks take place in order to avoid false positives,
I hope these are correct and enough.
I'm not 100% happy of the interface (too much redundancy),
but for the time being it could be OK.
Of course, any improvement is welcome.
Please consider to include these changes to the next mdadm
whatever release.
bye,
Signed-off-by: NeilBrown <neilb@suse.de>
After takeover, layout has no meaning for computing geo map for raid0
and raid4. Set layout to 0 for such cases. It can happen after
takeover operation when not all array information is reread.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When building mdadm.O2, set _FORTIFY_SOURCE to get more
warnings, and also build mdmon.O2 to find warnings in that
code too.
Then fix the warnings.
Suggested-by: Luca Berra <bluca@comedia.it>
Signed-off-by: NeilBrown <neilb@suse.de>
md supports new raid6 layouts to support conversion to and from
raid5 and well as DDF. Make sure restripe handles those, including
getting the order right for Q-syndrome calculation.
Signed-off-by: NeilBrown <neilb@suse.de>
Since we introduced O_DIRECT for device access we need
properly aligned buffers and IO requests. The reshape code
missed out on the conversion.
Signed-off-by: NeilBrown <neilb@suse.de>