Sorry, I wasn't paying close enough attention and missed the obvious.
.....
On Thursday October 18, snitzer@xxxxxxxxx wrote:
> On 10/18/07, Neil Brown <neilb@xxxxxxx> wrote:
> > On Wednesday October 17, snitzer@xxxxxxxxx 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
^^^^^^^^^^^^^^^^^^
This means there was an IO error. i.e. there is a block on the device
that cannot be read from.
It worked with earlier version of mdadm because they used a much
smaller bitmap. With the patch you mention in place, mdadm tries
harder to find a good location and good size for a bitmap and to
make sure that space is available.
The important fact is that the bitmap ends up at a different
location.
You have a bad block at that location, it would seem.
I would have expected an error in the kernel logs about the read error
though - that is strange.
What do
mdadm -E
and
mdadm -X
on each device say?
> > > 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)
> >
> > Could you please tell me the exact size of your device? Then should
> > be able to reproduce it and test a fix.
> >
> > (It works for a 734003201K device).
>
> 732456960K, it is fairly surprising that such a relatively small
> difference in size would prevent it from working...
There was a case once where the calculation was wrong, and rounding
sometimes left enough space and sometimes didn't. That is why I
wanted to know the exact size. I turns out it wasn't relevant in this
case.
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
