I come across a situation where external MD bitmaps aren't usable on any "standard" linux distribution unless special (non-trivial) actions are taken.
First is a small buglet in mdadm, or two. It's not possible to specify --bitmap= in assemble command line - the option seems to be ignored. But it's honored when specified in config file. Also, mdadm should probably warn or even refuse to do things (unless --force is given) when an array being assembled is using external bitmap, but the bitmap file isn't specified. Now for something more.. interesting. The thing is that when a external bitmap is being used for an array, and that bitmap resides on another filesystem, all common distributions fails to start/mount and to shutdown/umount arrays/filesystems properly, because all starts/stops is done in one script, and all mounts/umounts in another, but for bitmaps to work the two should be intermixed with each other. Here's why. Suppose I've an array mdX which used bitmap /stuff/bitmap, where /stuff is another separate filesystem. In this case, during startup, /stuff should be mounted before bringing up mdX, and during shutdown, mdX should be stopped before trying to umount /stuff. Or else during startup mdX will not find /stuff/bitmap, and during shutdown /stuff filesystem is busy since mdX is holding a reference to it. Doing things in "simple" way doesn't work: if I specify to mount mdX as /data in /etc/fstab, -- since mdX hasn't been assembled by mdadm (due to missing bitmap), the system will not start, asking for emergency root password... Oh well. So the only solution for this so far is to convert md array assemble/stop operation into... MOUNTS/UMOUNTS! And specify all necessary information in /etc/fstab - for both arrays and filesystems, with proper ordering in "order" column. Ghrm. Technically speaking it's not difficult - mount.md and fsck.md wrappers for mdadm are trivially to write (I even tried that myself - a quick-n-dirty 5-minutes hack works). But it's... ugly. But I don't see any other reasonable solutions. Alternatives are additional scripts to start/stop/mount/umount filesystems residing on or related to "advanced" arrays (with external bitmaps in this case) - but looking at how much code is in current startup scripts around mounting/fscking, and having in mind that mount/umount does not support alternative /etc/fstab, this is umm.. even more ugly... Comments anyone? Thanks. /mjt P.S. Why external bitmaps in the first place? Well, that's a good question, and here's a (hopefully good too) answer: When there are sufficient disk drives available to dedicate some of them for bitmap(s), and there's a large array(s) with dynamic content (many writes), and the content is important enough to care about data safety wrt possible power losses and kernel OOPSes and whatnot, placing bitmap into another disk(s) helps alot with resyncs (it's not about resync speed, it's about resync general UNRELIABILITY, which is another topic - hopefully a long-term linux raid gurus will understand me here), but does not slow down writes hugely due to constant disk seeks when updating bitmaps. Those seeks tends to have huge impact on random write performance. - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
