Re: Bitmap did not survive reboot

[Doug Ledford <dledford@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2544 bytes --]

On 11/10/2009 10:34 PM, Leslie Rhorer wrote:
>>  If the array isn't super performance critical, I would use mdadm
>> to delete the bitmap, then grow an internal bitmap with a nice high
>> chunk size and just go from there.  It can't be worse than what you've
>> got going on now.
> 
> 	I really dislike that option.  Doing it manually every time I boot
> would be a pain.  Writing a script to do it automatically is no more trouble
> (or really much different) than writing a script to mount the partition
> explicitly prior to running mdadm, but it avoids any issues of which I am
> unaware (but can imagine) with, say, trying to grow a bitmap on an array
> that is other than clean.  I'd rather have mdadm take care of such details.

I think you are overestimating the difficulty of this solution.  It's as
simple as:

mdadm -G /dev/md0 --bitmap=none
mdadm -G /dev/md0 --bitmap=internal --bitmap-chunk=32768 (or even higher)

and you are done.  It won't need to resync the entire device as the
device is already clean and it won't create a bitmap that's too large
for the free space that currently exists between the superblock and the
start of your data.  You can see the free space available for a bitmap
by running mdadm -E on one of the block devices and interpreting the
data start/data offset/superblock offset fields (sorry there isn't a
simply field to look at, but the math changes depending on what
superblock version you use and I can't remember if I've ever known what
superblock you happen to have).  No need to copy stuff around, no need
to take things down, all done in place, and the issue is solved
permanently with no need to muck around in your system init scripts as
from now on when you boot up the bitmap is internal to the array and
will be used from the second the array is assembled.  The only reason I
mentioned anything about performance is because an internal bitmap does
slightly slow down random access to an array (although not so much
streaming access), but that slowdown is mitigated by using a nice high
bitmap chunk size (and for most people a big bitmap chunk is preferable
anyway).  As I recall, you are serving video files, so your access
pattern is large streaming I/O, and that means the bitmap really
shouldn't be noticeable in your performance.

-- 
Doug Ledford <dledford@redhat.com>
              GPG KeyID: CFBFF194
	      http://people.redhat.com/dledford

Infiniband specific RPMs available at
	      http://people.redhat.com/dledford/Infiniband


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]