On 8 July 2018 at 18:23, Wols Lists <antlists@xxxxxxxxxxxxxxx> wrote: > 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 > It counts unallocated blocks?!?!?! whyyyyyyyyyy -- 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
