martin f krafft <[email protected]> writes: > Where is the write-intent bitmap stored? /lib/init/rw is available > r/w even before checkroot. I'd rather not move mdadm-raid around > because it took months to settle on the current position. So > instead, we should make sure that mdadm knows where to try to drop > its files.
I understand that you don't want to mess up the ordering. Although it solved the problem for me, that's just my simple test system. I initially stored the write-intent bitmap on the root file system because that was the earliest available file system as far as I knew. Moving it somewhere else is of course an option, and it would probably be a good thing if mdadm helped us users standardize both location and file name. But I don't see how /lib/init/rw can be used, as that is usually a ramfs on Debian: bj...@canardo:~$ df /lib/init/rw Filesystem 1K-blocks Used Available Use% Mounted on tmpfs 4100148 0 4100148 0% /lib/init/rw bj...@canardo:~$ ls -la /lib/init/rw total 4 drwxr-xr-x 4 root root 100 2010-01-16 12:03 . drwxr-xr-x 3 root root 4096 2008-08-24 22:16 .. drwxr-xr-x 2 root root 100 2010-01-16 12:03 .mdadm -rw-r--r-- 1 root root 0 2010-01-16 12:03 .ramfs drwxr-xr-x 2 root root 60 2010-01-16 12:04 sendsigs.omit.d Writeable is not enough, it has to be persistent too. The bitmap will have to survive a crash (e.g. sudden power failure) to be useful. One could maybe imagine copying the bitmap from a readonly rootfs to /lib/init/rw on boot and start the array with it there, then moving the bitmap back to the rootfs (using mdadm --grow) later when the root is writeable? But this would just add unnecessary complexity. It would require some "mdadm-raid-late" initscript anyway, and you could just as well add one handling only arrays with external write intent bitmaps. Anyway, some check should probably go into the current mdadm initscripts (both /usr/share/initramfs-tools/scripts/local-top/mdadm and /etc/init.d/mdadm-raid) to avoid them starting an array with an external bitmap if the bitmap is unwriteable, as it really is better to start it manually later than losing the bitmap. Unless the array contains a critical filesystem, of course, in which case I don't think an external bitmap can be used. Phew, I'm starting to see some of the ordering problems you are facing, and I guess this is only the top of the iceberg... I have a lot of respect for the job you are doing sorting this out. Thanks. Bjørn -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
