DM and MD come a little closer [LWN.net]

By Jonathan Corbet
April 20, 2010

The management of RAID arrays in the kernel is a complicated task - and one upon which the fate of much data relies. Given that, it would make sense to have a single set of RAID routines which is improved by all. What the Linux kernel has, instead, is three different RAID implementations: in the multiple device (MD) subsystem, in the device mapper (DM) code, and in the Btrfs filesystem. It has often been said that unifying these implementations would be a good thing, but that is not easy and thus far, it has not happened.

MD maintainer Neil Brown has now taken a step in this direction with the posting of his dm-raid456 module, a RAID implementation for the device mapper which is built on the MD code. This patch set set has the potential to eliminate a bunch of duplicated code, which can only be a good thing. It also brings some nice features, including RAID6 support, multiple-target support, and more to the device mapper layer.

This is early work which, probably, is not destined for the next merge window. The response from the device mapper side has been reasonably positive, though. So, with luck, we'll someday have both subsystems using the same RAID code.

Index entries for this article
Kernel	Block layer/RAID
Kernel	RAID

DM and MD come a little closer

Posted Apr 22, 2010 14:10 UTC (Thu) by butlerm (subscriber, #13312) [Link]

Filesystem internal RAID implementations shouldn't count on the list. A handful of minor utility routines aside such implementations aren't candidates for general use at all. They are completely different in character, draw their advantages due to filesystem level knowledge of what is going on at a very low level, and are more or less completely unfactorizable.

It is certainly conceivable that an interface could be developed to speed RAID recovery of a disk containing conventional filesystems by indicating which sectors are actually in use (couldn't TRIM be used for that?), but the problem is, like flash block devices, a modern RAID implementation is rapidly taking on more of the character of a filesystem itself, in terms of the complexity of on disk data structures, journalling, metadata etc. And it often isn't particularly efficient to run two such implementations on top of each other, even though often convenient in practice.

MD is wonderful

Posted Apr 23, 2010 4:29 UTC (Fri) by ringerc (subscriber, #3071) [Link] (1 responses)

I'd just like to take this opportunity to note that the "md" driver and utilities are absolutely wonderful, and make my life as a sysadmin vastly easier. I use them in strong preference to hardware RAID unless I really need a battery-backup unit so I can enable write caching.

I recently hot-added two more 1TB disks to an existing 8-disk RAID 6 array, and effortlessly reshaped it onto the new disks then grew it to size. Absolutely fuss free and trivial with mdadm. I'm beyond impressed.

Anything that brings this kind of power, control, and reliability to the dmraid layer can only be a good thing.

If the "md" driver knew how to use some battery-backed RAM on a PCIe card as write cache and write-intent bitmap storage, I'd never touch a hardware RAID controller again. As it is, I only do so when I have to run a high performance database, which just *can't* really be done without hardware write caching.

Now, if only LVM as an overlay was md-aware for striping and (sigh) honoured write barriers, so RAID-aware file systems could operate reasonably safely and efficiently on top of LVM-on-MD. It's a shame to have MD's usefulness somewhat crippled by LVM's deficiencies.

MD is wonderful

Posted Apr 23, 2010 15:51 UTC (Fri) by nix (subscriber, #2304) [Link]

I think LVM *does* honour write barriers these days. At least things like the linear target do, which is all you normally use when using LVM-on-MD.