On Monday April 28, taeuber@xxxxxxx wrote: > Hallo Neil, > > Neil Brown <neilb@xxxxxxx> schrieb: > > On Thursday March 13, aia21@xxxxxxxxx wrote: > > > > > > Is there a better way to do this? I am hoping someone will tell me to > > > use option blah to utility foo that will do this for me without having > > > to break the mirror twice and resync each time. (-; > > > > Sorry, but no. This mode of operation was never envisaged for md. > > I would always put the md/raid1 devices below the LVM. > > could you write in some short words what in the design prohibits us to grow a raid1 on a grown lvm? By default, the metadata for an md array is stored near the end of each device. If you make the device larger, you lose the metadata. This could be address for on-line resizing by having some protocol whereby the LVM layer tells whoever is using it that it is about to become larger, so that the metadata can be updated and moved, but that is probably more hassle than it is worth. If you use version 1.1 or 1.2 metadata, the metadata is stored at the start of the device, so it doesn't get lost. However the metadata has recorded in it the amount of usable space on the device. When you make the device bigger you would need to update this number. There is currently no way to update this for an active array. You can stop the array, and the re-assemble it with --update=devicesize this will update the field in the metadata which records the size of each device. You will then be able to grow the array to make use of all the space. It might not be to hard to make it possible to tell md that devices have grown.... maybe one day :-) NeilBrown > We wanted to do the same: > > > mutliple RAID1 (aoe targets) > on top of > multiple LVMs > on top of > gigantic RAID6 > > > Thanks > Lars > -- > Informationstechnologie > Berlin-Brandenburgische Akademie der Wissenschaften > Jägerstrasse 22-23 10117 Berlin > Tel.: +49 30 20370-352 http://www.bbaw.de -- 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
