> If you have a temporary space for your data, I'd suggest you move it > out and go for an internal bitmap solution. It certainly beats the For 8 Terabytes of data? No, I don't. I'm also not really keen on interrupting the system ( in whatever fashion ) for six to eight days while I copy the data out and back or taking the primary copy offline while I re-do the array just so I can implement an internal bitmap. It's much easier to handle the external situation one way or the other. > patch work you're going to have to do on the startup scripts (and > every time you update mdadm, or the distro). That's why I am leaning strongly toward the lower value script, which in fact I have already done. Of course, it's also trivial to disable it. Updating mdadm or the distro won't affect the mount script. At most I would only have to rename the link, and then only if the mdadm startup link gets re-numbered, which is unlilkely. Creating the following script and one symlink to it are hardly "patchwork" in any significant sense: #! /bin/sh # Explicitly mount /dev/hda4 prior to running mdadm so the write-intent # bitmap will be available to mdadm echo Mounting RAID bitmap... mount -t ext2 /dev/hda4 /etc/mdadm/bitmap -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
