My particuarly interest in it is to have working RAID5 and RAID1 code so that my servers have fairly reliable data storage. I try to keep the other personalities working (RAID0, Linear, Multipath, RAID6) but do not use them much if at all. In particular I have little interest in multipath. I'm not even sure that 'md' is the right place for multipath support. But maybe it is.
There is a related but separate set of code known as "DM" for "Device Mapper". I do not maintain it or know much about it.
It has been suggested that md and dm should merge. This is probably a good idea, but no-one seem actually motivated to do it. Maybe one day someone will. Or maybe one day dm will include all the functionality of md and I can start using it and give up on md. Only time will tell.
I have written a tool for management of MD arrays. You can see my mdadm page for more details.
Patches
I don't keep a separate set of raid patches. I just keep a bunch of current patches which might be for RAID, and might be for NFS, or even something else. You can find them at http://neilb.web.cse.unsw.edu.au/patches/linux-devel/.News
14 December 2004, 22:42 UTCLinux md/raid update - UPDATED-1
Further to my md/raid tests reported earlier I retested raid0 throughput on 2.6 as the 'write throughput' numbers I got in the first run were very strange. The second run shows much more reasonable number.
I also tested raid5 with a degraded array (one drive missing). This resulted in slower reads than a fully functional raid5, and same-speed writes.
13 December 2004, 23:08 UTCLinux md/raid throughput measurements
Following some comments on the linux-raid mailing list about poor throughput for raid5 in 2.6, I did some systematic measurement on my test machine to look for patterns. And the result were illuminating.
I compared raid0 with raid5 in 2.4.27 and 2.6.9. The results showed that reading from raid5 is significantly slower in 2.6 (as reported) and also that writes were quite a bit slower too, even for raid0 (raid0 reads improved in 2.6). However I didn't get the same degree of slow down that has been reported elsewhere.
UPDATE: more results are available in a subsequent article, showing that the raid0 write through shown here is misleading.
11 June 2004, 6:42 UTC--grow option for "linear" md arrays
I've just been working on an enhancement for Linux "MD" linear arrays which allows them to be enlanged.
More specifically, a new device (typcially disk drive) can be added to the end of an active linear array now. The size increases accordingly.
You can find patches for mdadm and 2.6.7-rc3-mm1.
It is still a work in progress, as it isn't documented, some of the code doesn't report errors very nicely, and I realised that there is some work needed in md.c with respect to handling new superblocks.
I really should do the new-superblock code in mdadm and get it all tidied up.
4 June 2004, 8:19 UTCNew "mdadm"
I have just released a new version of mdadm - 1.6.0.
Mdadm is my tool for managing Linux Software RAID arrays.
This release included initial support for a --grow mode that allows resizing on-line arrays. Naturally this requires kernel support to be able to work. The 2.6.7-rc2-mm1 Linux kernel has support for changing the active size of component devices and changing the number of drives in a RAID1.
I hope to add support for adding drives to a linear array soon, and adding drives to a RAID5 eventually.
I had hoped to get support for the new-style superblocks into this release, but it just didn't happen. Maybe next time.
Random thoughts
The following items are various random thoughts about the MD driver, what needs to be fixed and what enhancements might be useful.
13 May 2004, 5:55 UTCsysfs??
It might be nice to make information and management available through sysfs. Maybe.
13 May 2004, 5:52 UTCEvent monitoring
Events happen in raid arrays, such as device failure and resync. It would be nice to know when they happen.
polling /proc/mdstat is one option, but it isn't perfect.
13 May 2004, 3:24 UTCauto-correcting read errors
Write errors must always fail a device as even if there was a cable problem rather than a media problem, the drive will be inconsistant with the array after the write failure and so cannot be trusted.
However read errors do not have to be fatal. If the device can over-write a bad sector, or remap to elsewhere, then it makes sense to regenerate the data from redundant info and re-write.
13 May 2004, 2:58 UTCconsistancy check/correct
It would be good to ask an array to check if it is in-sync, and optionally to correct any errors.
This requires a good interface and an efficient implementation.
13 May 2004, 1:23 UTCNew style RAID superblock
The md driver in 2.6 has support for a new style of superblock. This needs user-space support
13 May 2004, 0:56 UTCRAID10
While it is quite possible to provide a RAID10 array by making some RAID1 arrays and combining them with RAID0, this approach has some problems.