On 27 Apr 2017, John Stoffel spake thusly: > No, big MD devices are sync'd in parallel assuming MD thinks they're > on seperate devices. Now in this case I admit I might have jumped the > gun, but I'm mostly commenting on the use of multiple MD RAID setups > on a single pair of disks. > > It's inefficient. It's a pain to manage. You lose flexibility to > resize. Aside: the storage server I've just set up has a different rationale for having multiple mds. There's one in the 'fast part' of the rotating rust, and one in the 'slow part' (for big archival stuff that is rarely written to); the slow one has an LVM PV directly atop it, but the fast one has a bcache and then an LVM PV built atop that. The fast disk also has an md journal on SSD. Both are joined into one LVM VG. (The filesystem journals on the fast part are also on the SSD.) So I have a chunk of 'slow space' for things like ISOs and video files that are rarely written to (so a RAID journal is needless) and never want to be SSD-cached, and another (bigger) chunk of space for everything else, SSD-cached for speed and RAID-journalled for powerfail integrity. You can't do that with one big md array, since you can't have one array which is partially journalled and partially not. (You *can*, with the aid of dm, have one array which is partially bcached and partially not, but frankly messing about with direct dm linears seemed pointlessly painful. It's annoying enough to set up an md->bcache->LVM setup at boot: adding dmsetup to that as well seemed like pain beyond the call of duty.) (... actually it's more complex than that: there is *also* a RAID-0 containing an ext4 sans filesystem journal at the start of the disk for transient stuff like build trees that are easily regenerated, rarely needed more than once, and where journalling the writes or caching the reads on SSD is a total waste of SSD lifespan. If *that* gets corrupted, the boot machinery simply re-mkfses it.) -- NULL && (void) -- 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
