Re: BUGS: internal bitmap during array create

[Eli Stair <estair@ilm.com>]

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



I've provided the requested info, attached as two files (typescript output):

BUG 1)

/ create-array-with-internal-bitmap.out
# this file contains the full series of creation, mkfs, examine
# and mount commands/errors

The only obvious detail I can detect is the 'Chunksize' shown in the 
superblock detail.  The value set when creating the array with 
'-binternal' is "1MB", while after removing and re-creating the bitmap, 
it is set to "128MB".  After this step (and the chunksize increasing), 
initial tests show this to work fine.

One thing I noted, the initial resync time is /incredibly/ shortened 
when created with an internal write-intent bitmap... completing in 
between ONE and TEN minutes vs. the average 200min. initial sync time 
for a 1-2 TB array without the bitmap!  I don't understand how this can 
occur safely, since the write speed of the raw drives isn't enough to 
zero all sectors for sanitizing the RAID blocks in that time period.... 
is this then left in an unclean/dangerous underlying state?

BUG 2)

/ create-array-with-external-bitmap.out
# this file contains attempts to set the bitmap-chunk for external
# bitmap file, unsuccessfully.

This errored out no matter the values I tested.  In summary, using

--bitmap-chunk=[>=128] resulted in:
   mdadm: size set to 143374336K
   mdadm: RUN_ARRAY failed: No space left on device


--bitmap-chunk=[<=64] resulted in:
   mdadm: size set to 143374336K
   mdadm: RUN_ARRAY failed: Cannot allocate memory



Cheers,

/eli


Neil Brown wrote:
> On Wednesday October 11, estair@ilm.com wrote:
>  >
>  > After realizing my stupid error in specifying the bitmap during array
>  > creation, I've triggered a couple of 100% repeatable bugs with this
>  > scenario.
>  >
>  >
>  > BUG 1)
> ....
>  >
>  >
>  > Strangely, whatever the underlying cause is, ext3 seems immune (at least
>  > in brief testing) to this.  I can create and mount an ext3 filesystem on
>  > top of the array that xfs dies trying to mount.
>  >
>  > In the case where the array is created with bitmap at build time, if I
>  > wait until resync is completed, do a 'mdadm -Gb none' followed by 'mdadm
>  > -Gb internal', I can then safely create the XFS filesystem and mount
>  > it.
> 
> Can you get me the output of
>    mdadm -X some-component-device
> both after the creation with a bitmap, and after the bitmap has been
> hot-removed and hot-added.
> Just for good measure, include the "mdadm -E" output at the same
> times.
> 
>  >
>  > BUG 2)
>  >
>  > Another bitmap failure during create time:  MDADM dies with an error
>  > after creating the array, when it tries to assemble it, with an
>  > external-file bitmap (on ext3):
>  >
>  >
>  >      [root@gtmp01 GTMP]# mdadm -C /dev/md0 -f --chunk=512 --level=10
>  > -n14 -po2 -e1.2 -bESC[1P^M[root@gtmp01 GTMP]# mdadm -C /dev/md0 -f
>  > --chunk=512 --level=10 -n14 -po2 -e1.2 -b/var/tmp/bitmap 
> /dev/mapper/mpath*
>  >      mdadm: RUN_ARRAY failed: Cannot allocate memory
>  >      mdadm: stopped /dev/md0
> 
> I thought I had fixed this in 2.5, but on reflection that might not
> fixed it for 64bit hosts. Can you try explicitly setting the
> --bitmap-chunk size such that there will be fewer than 1,000,000
> chunks?
> 
> NeilBrown
> -
> 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
> 


[-- Attachment #2: create-array-with-external-bitmap.out --]
[-- Type: application/octet-stream, Size: 3250 bytes --]

[-- Attachment #3: create-array-with-internal-bitmap.out --]
[-- Type: application/octet-stream, Size: 38155 bytes --]