TODO list for mdadm

I not only have a TODO list for linux/md/raid, but for mdadm -- the userspace md management tool -- too.

It is mostly focussed on getting 2.0 ready for release, but there are some bits that can wait until after 2.0

It includes a test-suite, a '--hostid' flag to tie arrays to host and make automatic assembly more possible, and improvements to support for version-1 superblocks.

testsuite

I really need a testsuite for mdadm. It does too many things and has broken too often for me to be confident in a new release without one.

This will probably involve creating some loop-back devices and building lots of different arrays with them.

It needs to test version0.90 and version1 superblocks, raid0, 1, 4, 5, 6, 10, linear, multipath, and various flavours of these (particularly raid10).

It needs to auto-create names in /dev.

It needs to work with config files and without

All different options in all different modes need to be tested.

Finding the right structure for it all will be the hard bit.

better error messages

mdadm should never simply report an error code from the kernel, as the codes were not designed for md. It should always interpret and try to explain what really is going wrong. With --verbose it should sometimes give even more detail.

bitmap with version-1 superblock

When creating a verion-1 array, we should leave room for an internal superblock, and allow it to be added afterwards.

convert a single device into a linear

When creating a linear, it would be good to preserve all the data on the first drive. As the superblock will overwrite some it it, that bit should be copied to the second drive. But the user should be able to over-ride this.

hostid

This is a biggy.

The reason I don't like auto-discovery and auto-assembly is that if you pull drives from one machine and plug them into another, they might get autoassembled in the wrong place.

The fix for this is to encode something about the host machine into the superblock so that 'foreign' devices can be recognised. A 'hostname' would be ideal, if this were available.

--hostid=XXX would, on create, encode XXX, or a hash thereof into the UUID or NAME field of the superblock, and on assemble would look for only those uuids.

--assume-clean for --create

This currently works for --build. It is rather dangerous for --create, but somepeople want it for testing, so maybe....

have --add remove the device first if it is failed

This is what people seem to expect. Either we do it, or we give a better error message.

Version-1 superblocks

There are currently some oddities when reporting on version-1 superblocks as spares are handled differently, and the position in the array is different from the role in the RAID. This all needs to be resolved.

check and remove old superblocks on create

When creating an array we need to check for old superblcoks of all versions, and remove any that might confuse future assembly.