> Uhm. DM sort of does (at least where the morphing amounts to resyncing a > part of the stripe, ie adding a new mirror, RAID1->4, RAID5->6 etc). > Freeze, load new mapping, continue. The point is that these trivial "morphings" can be achieved with limited effort regardless of whether you do it via EMD or DM. Implementing this in EMD could be achieved with perhaps 8 hours work with no significant increase in code size or complexity. This is part of why I find them "uninteresting". If we really want to talk about generic morphing, I think you'll find that DM is no better suited to this task than MD or its derivatives. > I agree that more complex morphings (RAID1->RAID5 or vice-versa in > particular) are more difficult to get right, but are not that often > needed online - or if they are, typically such scenarios will have > enough temporary storage to create the new target, RAID1 over, > disconnect the old part and free it, which will work just fine with DM. The most common requests that we hear from customers are: o single -> R1 Equally possible with MD or DM assuming your singles are accessed via a volume manager. Without that support the user will have to dismount and remount storage. o R1 -> R10 This should require just double the number of active members. This is not possible today with either DM or MD. Only "migration" is possible. o R1 -> R5 o R5 -> R1 These typically occur when data access patterns change for the customer. Again not possible with DM or MD today. All of these are important to some subset of customers and are, to my mind, required if you want to claim even basic morphing capability. If you are allowing the "cop-out" of using a volume manager to substitute data-migration for true morphing, then MD is almost as well suited to that task as DM. -- Justin - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
