Mike Snitzer wrote:
On 10/17/07, Bill Davidsen <[EMAIL PROTECTED]> wrote:
Mike Snitzer wrote:
mdadm 2.4.1 through 2.5.6 works. mdadm-2.6's "Improve allocation and
use of space for bitmaps in version1 metadata"
(199171a297a87d7696b6b8c07ee520363f4603c1) would seem like the
offending change. Using 1.2 metdata works.
I get the following using the tip of the mdadm git repo or any other
version of mdadm 2.6.x:
# mdadm --create /dev/md2 --run -l 1 --metadata=1.0 --bitmap=internal
-n 2 /dev/sdf --write-mostly /dev/nbd2
mdadm: /dev/sdf appears to be part of a raid array:
level=raid1 devices=2 ctime=Wed Oct 17 10:17:31 2007
mdadm: /dev/nbd2 appears to be part of a raid array:
level=raid1 devices=2 ctime=Wed Oct 17 10:17:31 2007
mdadm: RUN_ARRAY failed: Input/output error
mdadm: stopped /dev/md2
kernel log shows:
md2: bitmap initialized from disk: read 22/22 pages, set 715290 bits, status: 0
created bitmap (350 pages) for device md2
md2: failed to create bitmap (-5)
md: pers->run() failed ...
md: md2 stopped.
md: unbind<nbd2>
md: export_rdev(nbd2)
md: unbind<sdf>
md: export_rdev(sdf)
md: md2 stopped.
I would start by retrying with an external bitmap, to see if for some
reason there isn't room for the bitmap. If that fails, perhaps no bitmap
at all would be a useful data point. Was the original metadata the same
version? Things moved depending on the exact version, and some
--zero-superblock magic might be needed. Hopefully Neil can clarify, I'm
just telling you what I suspect is the problem, and maybe a
non-destructive solution.
Creating with an external bitmap works perfectly fine. As does
creating without a bitmap. --zero-superblock hasn't helped. Metadata
v1.1 and v1.2 works with an internal bitmap. I'd like to use v1.0
with an internal bitmap (using an external bitmap isn't an option for
me).
Unless there's a substantial benefit from using the 1.0 format, you
might want to go with something which works. I would suggest using
--bitmap-chunk, but the man page claims it doesn't apply to internal
bitmaps. It also claims the bitmap size is chosen automatically to best
use available space, but "doesn't work" seems an exception to "best
use." ;-)
It does appear that the changes to sb super1.c aren't leaving adequate
room for the bitmap. Looking at the relevant diff for v1.0 metadata
the newer super1.c code makes use of a larger bitmap (128K) for
devices > 200GB. My blockdevice is 700GB. So could the larger
blockdevice possibly explain why others haven't noticed this?
Could be, although I have arrays larger than that and haven't been
bitten. Then again, none of mine use the 1.0 metadata format as I
recall. Perhaps Neil will explain his thinking on these formats, I can
see 1.0 and 1.1, but the 1.2 format uses the 4k offset to no obvious
benefit. In any case, you have a workable solution, so you can move on
if time is an issue, or wait for Neil to comment on this. I didn't see
an obvious problem with the 1.0 code WRT bitmaps, but I looked quickly
and at a 2.6.3 source I had handy.
--
bill davidsen <[EMAIL PROTECTED]>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
