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/errorsThe 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@xxxxxxx 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
Attachment:
create-array-with-external-bitmap.out
Description: Binary data
Attachment:
create-array-with-internal-bitmap.out
Description: Binary data
