pvcreate to raid1 fails

[Jerry Feldman]

On 03/01/2010 07:41 PM, Benjamin Scott wrote:
> On Mon, Mar 1, 2010 at 5:48 PM, Jerry Feldman <gaf at blu.org> wrote:
>   
>> pe_align (128 sectors) must not be less than pe_align_offset
>> (36028797018963967 sectors)
>>     
>   By my calculations, the second number of sectors works out to 16
> million terabytes, which makes me suspect the diagnostic itself is
> broken, or being fed broken data.
>
>   
>> Nore that /dev/md1 is formatted ext4.
>>     
>   Are you trying to import an ext4 filesystem into LVM "in place"?  If
> so, that won't work.  You have to create a new (empty) LV (Logical
> Volume) and copy the filesystem into the LV.  You can do the copy in
> any number of ways, but mounting both and doing "cp -a" generally
> works.
>
>   If you just want to use /dev/md1 as a new empty PV (Physical
> Volume), then try erasing the filesystem superblock on /dev/md1 so LVM
> thinks it is blank.
>
>   WARNING: The following command will destroy all data on the filesystem!
>
> 	dd if=/dev/zero of=/dev/md1 bs=512 count=1
>
>   WARNING: The preceding command will destroy all data on the filesystem!
>
>   (I know you know what "dd if=/dev/zero" does; the warnings are for
> other readers.  (Who also don't care about data remanence.))
>
>   You can't do an in-place import of a filesystem to an LV because LVM
> LVs are structured entities which are not always linear, and LVM PVs
> contain metadata at the start (and maybe also the end), neither of
> which are how filesystems see block devices.  There are probabbly
> cases where it would be doable in theory, but I don't think anyone's
> bothered with code.
>
>   
>> What I am trying to do is to migrate my system (LVM on /dev/sda2) to raid1.
>>     
>   I'm not sure if I have the whole picture.  Let me pitch a scenario:
>
> Existing system is single disk, no RAID
> sda = Existing disk
> sda1 = Small boot partition
> sda2 = Large LVM PV
> LVM volume group name VolGroup00
> One or more filesystems and/or swap spaces in LVM LVs
> Goal: Migrate system to RAID 1 in-place
>
> # make a full backup of everything to offline media
> # test the backup
> # add new new disk as /dev/sdc
> # set partitions on sdc to be same or larger than sda
> # create degraded mirrors on new disk
> mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdc1 missing
> mdadm --create /dev/md1 --level=1 --raid-devices=2 /dev/sdc2 missing
> # initialize md1 as an LVM PV
> pvcreate /dev/md1
> # add new the PV to the existing VG (Volume Group)
> vgextend VolGroup00 /dev/md1
> # make sure that backup is still there
> # move data to new PV
> pvmove /dev/sda2 /dev/md1
> # get coffee, make sandwich, read book, etc.
> # remove the now unused old PV from old disk
> vgreduce VolGroup00 /dev/sda2
> # (things get vague now, 'cause I don't want to type everything)
> # (if anyone wants help on something, say so)
> # migrate boot partition to /dev/md0
> # zero first block of /dev/sda1 and /dev/sda2 to avoid confusion
> # add sda partitions to mirror sets
> mdadm --add /dev/md0 /dev/sda1
> mdadm --add /dev/md1 /dev/sda2
> # install boot loader on /dev/md0 and/or on /dev/sdc
> # maybe some other stuff that I forgot
>
>   
In this case, I set up /dev/md0 with no problem and my system is booting
with /dev/md0 as the /boot filesystem.

mdadm --create /dev/md1 --level=1 --raid-devices=2 /dev/sdc2 missing
The difference between the way I did it an your suggestion is I had
missing before the /dev/sdc2.
mdadm --create /dev/md1 --level=1 --raid-devices=2 missing /dev/sdc2
Was accomplished as was the 'dd if=/dev/zero of=/dev/md1 bs=512 count=1'

I tried this with and witout a filesystem on /dev/md1.



-- 
Jerry Feldman <gaf at blu.org>
Boston Linux and Unix
PGP key id: 537C5846
PGP Key fingerprint: 3D1B 8377 A3C0 A5F2 ECBB  CA3B 4607 4319 537C 5846


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
Url : http://mail.gnhlug.org/mailman/private/gnhlug-discuss/attachments/20100302/d2df2dc0/attachment.bin