I'm just in the process of upgrading the RAID-1 disks in my server, and have
started to experiment with the RAID-1 --grow command. The first phase of the
change went well, I added the new disks to the old arrays and then increased the
size of the arrays to include both the new and old disks. This meant that I had
a full and clean transfer of all the data. Then took the old disks out...it all
worked nicely.
However I've had two problems with the next phase which was the resizing of the
arrays.
Firstly, after moving the array, the kernel still seems to think that the raid
array is only as big as the older disks. This is to be expected, however
looking at the output of this:
[EMAIL PROTECTED] /]# mdadm --detail /dev/md0
/dev/md0:
Version : 00.90.03
Creation Time : Sat Nov 5 14:02:50 2005
Raid Level : raid1
Array Size : 24410688 (23.28 GiB 25.00 GB)
Device Size : 24410688 (23.28 GiB 25.00 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 0
Persistence : Superblock is persistent
Intent Bitmap : Internal
Update Time : Sat Jul 8 01:23:54 2006
State : active
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
UUID : 24de08b7:e256a424:cca64cdd:638a1428
Events : 0.5139442
Number Major Minor RaidDevice State
0 8 34 0 active sync /dev/sdc2
1 8 2 1 active sync /dev/sda2
[EMAIL PROTECTED] /]#
We note that the "Device Size" according to the system is still 25.0 GB. Except
that the device size is REALLY 40Gb, as seen by the output of fdisk -l:
/dev/sda2 8 4871 39070080 fd Linux raid autodetect
and
/dev/sdc2 8 4871 39070080 fd Linux raid autodetect
Is that a bug? My expectation is that this field should now reflect the size of
the device/partition, with the *Array Size* still being the original, unresized
size.
Secondly, I understand that I need to use the --grow command to bring the array
up to the size of the device.
How do I know what size I should specify? On my old disk, the size of the
partition as read by fdisk was slightly larger than the array and device size as
shown by mdadm.
How much difference should there be?
(Hint: maybe this could be documented in the manpage (please), NeilB?)
And lastly, I felt brave and decided to plunge ahead, resize to 128 blocks
smaller than the device size. mdadm --grow /dev/md1 --size=
The kernel then went like this:
md: couldn't update array info. -28
VFS: busy inodes on changed media.
md1: invalid bitmap page request: 150 (> 149)
md1: invalid bitmap page request: 150 (> 149)
md1: invalid bitmap page request: 150 (> 149)
md1: invalid bitmap page request: 150 (> 149)
md1: invalid bitmap page request: 150 (> 149)
md1: invalid bitmap page request: 150 (> 149)
md1: invalid bitmap page request: 150 (> 149)
md1: invalid bitmap page request: 150 (> 149)
md1: invalid bitmap page request: 150 (> 149)
md1: invalid bitmap page request: 150 (> 149)
md1: invalid bitmap page request: 150 (> 149)
...and kept going and going and going, every now and then the count incremented
up until about 155 by which point I shut the box down.
The array then refused to come up on boot and after forcing it to reassemble it
did a full dirty resync up:
md: bind<sda3>
md: md1 stopped.
md: unbind<sda3>
md: export_rdev(sda3)
md: bind<sda3>
md: bind<sdc3>
md: md1: raid array is not clean -- starting background reconstruction
raid1: raid set md1 active with 2 out of 2 mirrors
attempt to access beyond end of device
sdc3: rw=16, want=39086152, limit=39086145
attempt to access beyond end of device
sda3: rw=16, want=39086152, limit=39086145
md1: bitmap initialized from disk: read 23/38 pages, set 183740 bits, status: -5
md1: failed to create bitmap (-5)
md: pers->run() failed ...
md: array md1 already has disks!
raid1: raid set md1 active with 2 out of 2 mirrors
md1: bitmap file is out of date (0 < 4258299) -- forcing full recovery
md1: bitmap file is out of date, doing full recovery
md1: bitmap initialized from disk: read 10/10 pages, set 305359 bits, status: 0
created bitmap (150 pages) for device md1
md: syncing RAID array md1
md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec)
for reconstruction.
md: using 128k window, over a total of 19542944 blocks.
kjournald starting. Commit interval 5 seconds
EXT3 FS on md1, internal journal
EXT3-fs: recovery complete.
EXT3-fs: mounted filesystem with ordered data mode.
md: md1: sync done.
RAID1 conf printout:
--- wd:2 rd:2
disk 0, wo:0, o:1, dev:sdc3
disk 1, wo:0, o:1, dev:sda3
That was not really what I expected to happen.
I am running mdadm-2.3.1 which is the current version shipped with Fedora Core
right now, but I'm about to file a bug report to get this upgraded. A cursory
look through the Changelog didn't suggest anything about any of these things
being changed.
I get the feeling I am treading unchartered waters here, has anyone else done
this sort of this and/or seen this sort of problem before?
Reuben
-
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
