mdadm

A Nasty md/raid bug

There is a rather nasty RAID bug in some released versions of the Linux kernel. It won't destroy your data, but it could make it hard to access that data.

If you are concerned that this might affect you, the first thing you should do (after not panicking) is to gather the output of

mdadm -Evvvvs

and save this somewhere that is not on a RAID array. The second thing to do is read to the end of this note and then proceed accordingly. You most likely will never need use the output of that command, but if you do it could be extremely helpful.

Another mdadm release: 3.2.1

Hot on the heals of mdadm-3.1.5 I have just released 3.2.1.

The 3.2 series contains two particular sets of new functionality.

Firstly there is the "policy" framework. This allows us to set policy for different devices based on where they are connected (e.g. which controller) so that e.g. when a device is hot-plugged it can immediately be made a hot-spare for an array without further operator intervention. It also allows broader controller of spare-migration between arrays. It is likely that more functionality will be added to this framework over time

Secondly, the support for Intel Matrix Storage Manager (IMSM) arrays has been substantially enhanced. Spare migration is now possible as is level migration and OLCE (OnLine Capacity Expansion). This support is not quite complete yet and requires MDADM_EXPERIMENTAL=1 in the environment to ensure people only use it with care. In particular if you start a reshape in Linux and then shutdown and boot into Window, the Windows driver may not correctly restart the reshape. And vice-versa.

If you don't want any of the new functionality then it is probably safest to stay with 3.1.5 as it has all recent bug fixes. But if you are at all interested in the new functionality, then by all means give 3.2.1 a try. It should work fine and is no more likely to eat your data than any other program out there.

(14 comments)

Release of mdadm-3.1.5

The last release of mdadm that I mentioned in this blog was 2.6.1. As I am now announcing 3.1.5 you can see that I missed a few. That's OK though as I keep the release announcements in the source distribution so you can always go and read them there.

3.1.5 is just bugfixes. It is essentially 3.1.4 plus all the bug fixes found while working on 3.2 and 3.2.1. The list from the release announcement is:

Fixes for v1.x metadata on big-endian machines.

man page improvements

Improve '--detail --export' when run on partitions of an md array.

Fix regression with removing 'failed' or 'detached' devices.

Fixes for "--assemble --force" in various unusual cases.

Allow '-Y' to mean --export. This was documented but not implemented.

Various fixed for handling 'ddf' metadata. This is now more reliable but could benefit from more interoperability testing.

Correctly list subarrays of a container in "--detail" output.

Improve checks on whether the requested number of devices is supported by the metadata - both for --create and --grow.

Don't remove partitions from a device that is being included in an array until we are fully committed to including it.

Allow "--assemble --update=no-bitmap" so an array with a corrupt bitmap can still be assembled.

Don't allow --add to succeed if it looks like a "--re-add" is probably wanted, but cannot succeed. This avoids inadvertently turning devices into spares when an array is failed.

As you can see - lots of little bits and pieces.

I hope to release 3.2.1 soon. For people who want to use the Intel metadata format (Intel Matrix Storage Manager - IMSM) on Intel motherboards which have BIOS support and MS-Windows support, you should probably wait for 3.2.1. For anyone else, 3.1.5 is what you want.

3.2.1 should be released soonish. I probably won't even start on 3.2.2 for a couple of months, though I already have a number of thoughts about what I want to include. A lot of it will be cleaning up and re-organising the code: stuff I wanted to do for 3.2 but ran out of time.

As always, mdadm can be found via git at git://neil.brown.name/mdadm/ or from http://www.kernel.org/pub/linux/utils/raid/mdadm/.

(No comments)

Converting RAID5 to RAID6 and other shape changing in md/raid

Back in early 2006 md/raid5 gained the ability to increase the number of devices in a RAID5, thus making more space available. As you can imagine, this is a slow process as every block of data (except possibly those in the first stripe) needs to be relocated. i.e they need to be read from one place and written to another. md/raid5 allows this reshaping to happen while the array is live. It temporarily blocks access to a few stripes at a time while those stripes a rearranged. So instead of the whole array being unavailable for several hours, little bits are unavailable for a fraction of a second each.

Then in early 2007 we gained the same functionality for RAID6. This was no more complex than RAID5, it just involved a little more code and testing.

Now, in mid 2009, we have most of the rest of the reshaping options that had been planned. These include changing the stripe size, changing the layout (i.e. where the parity blocks get stored) and reducing the number of devices.

Changing the layout provides valuable functionality as it is an important part of converting a RAID5 to a RAID6.

mdadm 2.6.1 released

Yes, I forgot to announce 2.6 here, sorry about that.

2.6.1 is just some minor bug fixes. The release is motivated primarily by the fact that I have implemented raid6 reshape (i.e. add one or more devices to a raid6 while online). For the moment you need to collect patches from the linux-raid mailing list or wait for the next -mm release. They will hopefully be in 2.6.21-rc2. Earlier versions of mdadm can start a raid6 reshape with a new kernel, but there is one small case where it didn't quite do the right thing so I wanted to get that fix out.

2.6 introduced --incremental mode. This is intended for interfacing with 'udev'. When a new device is discoverred it is passed to "mdadm --incremental" and mdadm tries to include it in an md array if that is appropriate. As soon as all devices become available, the array is ready. Of course if one device is missing, we have a problem. Do we start the array degraded as soon as possible, or wait for the missing device to appear, possible waiting forever... No go answers to this question yet. mdadm allows you to try either.

(52 comments)

mdadm 2.5 released

I have just released mdadm 2.5. It is available from kernel.org and freshmeat knows about it.

It had originally expected this to be a fairly small update of assorted bug fixes. But when it came to putting it together, there turned out to be quite a lot of enhancements.

One - the major one - is the auto-assembly that I mentioned in an earlier past. Others were due to the fact that the maintainer of the Debian package took decided at the same time that it was time to sort through bug reports and forward some to me. Still others were just normal stuff on the linux-raid list.

All it all there is a reasonable amount of stuff in there. Hopefully it will get some testing, and even better: will get some feed back. The only way to make it the best is for people to tell me what is wrong with it.

(25 comments)

Auto-assembly mode for mdadm

Probably the most wanted feature of mdadm is auto-assembly. People want it to just do-the-right-thing. They want to simply be able to assemble all of their arrays without having to worry about creating and maintaining config files or anything like that.

I've always been against blind auto-assembly as it can (and occasionally has) cause problems when the wrong thing gets assembled.

However it is possible to find a middle ground, that isn't completely blind, but that requires minimal configuration effort. I've finally figured out how I want to implement that and scheduled the time to do it, and so it should appear in mdadm-2.5.

The core idea is to report the host name of each raid array. mdadm can then assemble every array that it can find, providing it is for 'this' host.

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.

mdadm 1.12.0 released

Well, mdadm 1.12.0 is out now. You can find it at the usual places: http://www.kernel.org/pub/linux/utils/raid/mdadm/ or http://www.cse.unsw.edu.au/~neilb/source/mdadm/.

It seems that whenever I try to type 1.12.0, it comes out as 1.20.0! It happened twice while creating this article, and it happened when I was creating the freshmeat announcement. I noticed just after I clicked the final 'commit' button. I looked around to see if there was any way to update a pending release, and there wasn't. I guess that makes sense as I had already been asked to check it.

Anyway, the mail went of out to mdadm-subscribers telling them that 1.20.0 was released :-( But when the daily fm-news came out, someone had corrected my blunder to 1.12.0 (I just mistyped it again!). Thankyou to freshmeat!

Now to get stuck into a new release of mdadm 2.0-devel. I want to add a '--hostid' option so that mdadm can determine if a given array was create for "this" host, and can then automatically assemble it safely.

(No comments)

New "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.

(15 comments)