On Wed, 19 Sep 2012 20:34:11 +0200 Markus Irle <tha.bear@xxxxxxxxx> wrote: > Hi Neal, > > On Wed, Sep 19, 2012 at 3:42 AM, NeilBrown <neilb@xxxxxxx> wrote: > > On Sun, 16 Sep 2012 01:32:06 +0200 Markus Irle <tha.bear@xxxxxxxxx> wrote: > > > >> I'm running 3.2 (3.2.0-31-generic, latest in current Ubuntu release 12.04) now. > > > > Sorry, I got that wrong. > > That commit is the one that introduced the bug. > > > > It's fixed by 667a5313ecd7308d which will be in 3.6, and is being > > back-ported to most -stable kernels, thought it doesn't seem to have arrived > > in any yet. > > > > Maybe you can ask Ubuntu to provide a kernel containing that commit? > > Or compile your own? > > > > Or find a kernel older than 3.2... > > Ok, I'm a bit confused. Me too it would seem - sorry. I was thinking of a RAID0 problem with similar symptoms. > > I was running 2.6.38 when I replaced the drives and grew the array. > Apparently growing went fine, because I was using the array for a > couple of weeks. But it didn't write the correct metadata (0.90), thus > reassembling after boot fails (or rather is the wrong size). > > I tried booting with 3.0.0, 3.2.0 and 3.5.0 with exactly the same results. > > I feel that no matter what kernel, as long as the metadata's wrong, I > can't assemble it correctly, correct? Yes, the metadata has lots the most-significant-bit of the 'size'. So it should be sufficient to: mdadm -G /dev/md2 --size 2930266432 where the size is calculated as the current "used device size" plus 2^31. You could probably just do "--size max" This will cause a resync of the 2G of data which is probably unnecessary, but is awkward to avoid. NeilBrown
Attachment:
signature.asc
Description: PGP signature
