On Wed, 14 Mar 2012 08:51:44 +0100 David Brown <david@xxxxxxxxxxxxxxx> wrote: > On 14/03/2012 07:27, NeilBrown wrote: > > On Wed, 14 Mar 2012 07:17:46 +0100 keld@xxxxxxxxxx wrote: > > > >> Hi Neil > >> > >> What is the problem with adding space to the 'far' layout? > >> > >> I would think you could just create the new array part 1 from the > >> old array part 2, and then sync the new array part 2 with the new > >> array part 1. (in the case of a far=2 array, for n>2 similar > >> constructs would apply). > > > > If I understand your proposal correctly, you would lose redundancy > > during the process, which is not acceptable. > > > > That's how I understood the suggestion too. And in some cases, that > might be a good choice for the user - if they have good backups, they > might be happy to risk such a re-shape. Of course, they would have to > use the "--yes-I-really-understand-the-risks" flag to mdadm, but other > than that it should be pretty simple to implement. Patches welcome :-) (well, actually not - I really don't like the idea. But my point is that these things turn out to be somewhat more complicated than they appear at first). > > For a safe re-shape of raid10, you would need to move the "far" copy > backwards to the right spot on the growing disk (or forwards if you are > shrinking the array). It could certainly be done safely, and would be > very useful for users, but it is not quite as simple as an unsafe re-size. Reshaping a raid10-far to use a different amount of the device would certainly be possibly, but is far from trivial. One interesting question is how to record all the intermediate states in the metadata. NeilBrown > > mvh., > > David > > > > If I don't understand properly - please explain in a bit more > > detail. > > > > Thanks, NeilBrown > >
Attachment:
signature.asc
Description: PGP signature
