mdadm 2.5 released

26 May 2006, 10:14 UTC

I have just released mdadm 2.5. It is available from 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.


(16 June 2006, 11:26 UTC)
mdadm-2.5 - memory leak?

I'm experiencing a problem after upgrading mdadm from 2.4-r1 to 2.5. The memory, mdadm is using in daemon mode, is constantly growing... Back to the old version and everything is fine again. Could you comment this issue.


memory leak (23 June 2006, 13:04 UTC)

Yes, there was a memory leak. It's fixed in 2.5.1 (though I'm hoping to put a 2.5.2 out before the end of June - there are a couple more bugs.... there always are :-)


Re: mdadm 2.5 released (13 July 2006, 05:43 UTC)
Maybe I don't know how things are done around here...but I feel like this should be more conspicuously noted...I googled mdadm and grabbed 2.5 as it was the last .tgz on the page. Yes, my haste made waste, but if you still wish to offer version 2.5 perhaps you could configure apache at with a IndexOptions VersionSort so 2.5.2 is the last listed .tgz?


Re: mdadm 2.5 released (13 July 2006, 11:08 UTC)

Great work Neil, thnx! I just updated my linux with the buildin it8212 drivers, going from emulated scsi ata devices to direct ata, and fixed my software array with your tool. I wouldn't be able to have done this without mdadm :D


Re: mdadm 2.5 released (23 July 2006, 19:48 UTC)
Complete God-send, have a 8TB array very redundant except for one 'small' issue the @#$%#$%^@# mdadm.conf file on the boot volume. re-loaded linux on the boot drive and luckily was able to pull down mdadm 2.5 and re-assembled & re-created the mdadm.conf file! :) Saved me from probably a 1-2weeks worth of doing disk dumps to find the block with a backup copy of the old one. (ok, real lesson here which I should KNOW by heart, have backups of main config files. Properly chastised. :)


Re: mdadm 2.5 released - VersionSort (24 July 2006, 00:32 UTC)

That web server is running Apache 1.3 which doesnt seem to understand VersionSort.

So I've put in a LATEST.tgz symlink and a file LATEST-is-mdadm-2.5.2 and will try to keep it uptodate.


Re: mdadm 2.5 released (31 August 2006, 16:31 UTC)

Hi, Kind of a general mdadm problem here, but I am using 2.5.2, so...

I need mdadm to dynamically redsicover failed paths in a multipath device

I have two cards, qlogic 2400 fiber channel cards, connecting to my SAN and when I pull one cable, everything works fine, the system fails over nicely to the other card and one of the other devices in my multipath device.

But, when the fiber is reconnected and everything is fine as far as the OS is concerned, mdadm refuses to automatically rediscover those paths, I have to manually

mdadm /dev/md0 -f /dev/sdb -r /dev/sdb -a /dev/sdb

This is a problem. Other packages (Sun's md packages, IBM's sdd/vpath system) work dynamically, why not mdadm?

I'm very happy with your product otherwise, but the need for dynamic failover is really bugging.




Re: mdadm 2.5 released (23 January 2007, 18:12 UTC)

Just wanted to say "thank you!" for the wonderful 'mdadm' package; I recently lost a disk in an array, and found the process of adding a replacement, and rebuilding the array, to be surprisingly easy. Thanks again!

-jesse, in Sacramento CA, USA.


Comment (12 February 2007, 09:06 UTC)
Is it possible to tell mdrecoveryd to wait a while and do it's work out of hours?


Re: mdadm 2.5 released (12 February 2007, 09:26 UTC)

Not exactly.

If it is optional work, such as a check/repair, then you obviously only tell it to do that at the appropriate time, and you can stop if by echoing 'idle' to 'resync_action'.

If there is work the needs to be done, the md will try to do it straight away. The best you can do is slow it down substantially. If you echo '1' to /sys/block/mdX/md/sync_speed_min then the resync will be very very slow. When 'out of hours' comes around, write a bigger number and it will go faster again.