On 08/07/18 18:29, Weedy wrote: > On 7 July 2018 at 10:28, Michael Niewöhner <linux@xxxxxxxxxxxxxx> wrote: >> Hi all! >> >> It would be really great to get similiar behaviour in linux raid. I'm currently >> trying to figure out how much work it would mean to implement this feature. >> I have never worked on linux raid source before so I may be completely wrong. >> Feel free to correct me. > > Assuming I'm not wrong (user here, not dev) I thought that's what replace does? > # mdadm /dev/md0 --add /dev/sdNEW > # mdadm /dev/md0 --replace /dev/sdOLD --with /dev/sdNEW > > If sdOLD accepts reads I thought this was pretty much "dd OLD NEW" > internally, the only hiccup being if sdOLD is really dying or full on > dead and then you need to recreate the data from parity. No - this is exactly what Michael is trying to avoid. If there's only 1TB of data on the array spread evenly over the three disks, he wants to copy only the 333GB that are in use. The problem with this is that (a) MD has no idea which bits of the disk are in use and which are not, and (b) just copying the bits that are in use will leave the unused bits in an unsync'd state, which will then moan blue murder on a check. It would make sense to prioritise that used stuff, but you do need to copy everything. If, however, we could get TRIM to actually zero the disk, that might well speed things up. It will need a lot of thinking through, though. It's a lot trickier than it sounds. Cheers, Wol -- 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
