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 [off-list ref] wrote:

quoted

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.

quoted

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@vger.kernel.org
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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html