> mount -t ext2 /dev/hda4 /etc/mdadm/bitmap I would suggest you mount the partition using UUID, just in case one day the disk decided to change its name, like what happened to me a while back. On Wed, Nov 11, 2009 at 11:13 AM, Leslie Rhorer <lrhorer@xxxxxxxxxxx> wrote: >> 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 > -- Majed B. -- 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
