[linux-lvm] A hint on a process

[linux-lvm] A hint on a process

[Georges Giralt]

Hello !
I've a system (now on Ubuntu 9.04, but initially on a Fedora ) set up as
follow :
There are two RAID1 software raid arrays (md0 , which is around 100 Mb
and holding an Ext2 FS for use in booting, md1 occupying the rest of the
space used as a PV for LVM) made on a couple of old 160 GB disks.

On the LVM VG0 are a lot of LV onto which Ubuntu is installed.

One of the two disks failed. I can't find a 160 GB replacement. Only 320
Gb for the smallest availlable disk near where I live.

So I plan to move the system to 320 GB disks and, if possible, not
wasting the 320-160 difference....
The process I thought about is as follow :

1) insert one 320 disk in both arrays (after partitioning it correctly,
100 Mb for the first partition and the remaining for the second.)

2) wait for the raid1 to synchronize.

3) mark the remaining 160 GB disk as failed and remove/replace with
another 320 GB disk set up as the first.

4) wait for the arrays to reconstruct/synchronize.

5) Extend the PV my Volume Group is build on (md1 in this case)

6) enjoy a beer...

What do you think of my method ? Is it a good one or am I missing
something ? You will have understood that losing data is not an option ...
Many thanks in advance for your answers, critics and pointers...
Regards.

-- 
If the only tool you have is a hammer, you tend to see every problem as a nail.
                Abraham Maslow
A British variant :
Any tool can serve as a hammer but a screwdriver makes the best chisel. 

Re: [linux-lvm] A hint on a process

[Stuart D Gathman]

On 12/06/2010 05:36 PM, Georges Giralt wrote:
> Hello !
> I've a system (now on Ubuntu 9.04, but initially on a Fedora ) set up as
> follow :
> There are two RAID1 software raid arrays (md0 , which is around 100 Mb
> and holding an Ext2 FS for use in booting, md1 occupying the rest of the
> space used as a PV for LVM) made on a couple of old 160 GB disks.
>
> On the LVM VG0 are a lot of LV onto which Ubuntu is installed.
>
> One of the two disks failed. I can't find a 160 GB replacement. Only 320
> Gb for the smallest availlable disk near where I live.
>
> So I plan to move the system to 320 GB disks and, if possible, not
> wasting the 320-160 difference....
> The process I thought about is as follow :
>
> 1) insert one 320 disk in both arrays (after partitioning it correctly,
> 100 Mb for the first partition and the remaining for the second.)
>
> 2) wait for the raid1 to synchronize.
>
> 3) mark the remaining 160 GB disk as failed and remove/replace with
> another 320 GB disk set up as the first.
>
> 4) wait for the arrays to reconstruct/synchronize.
>
> 5) Extend the PV my Volume Group is build on (md1 in this case)
>
> 6) enjoy a beer...
>
> What do you think of my method ? Is it a good one or am I missing
> something ? You will have understood that losing data is not an option ...
> Many thanks in advance for your answers, critics and pointers...
> Regards.
Your method will fail because the raid superblock is at the end of the
partition.

I use and recommend this variation:

1. Replace 160 with 320, allocate 2 partitions to match (or slightly
exceed if geometry requires) the partitions on
the 160.  Synchronize. 

2. Replace the 2nd 160, resynchronize. 

3. Add a 3rd raid1 with the remaining space, and extend the VG with the
additional PV.

If your system can support 3 drives, you can always partition to mirror
everything despite size mismatches.  For example,
step 3 would become:

3a. reinstall the 160 and allocate 2 80g partitions on the 160 (which is
no longer the default boot drive).  Allocate an 80g partition on each
320 to mirror the 2 80g partitions giving md2 and md3.  Mirror the
remaining 80g in each 320 for md4.  Extend the VG with the addition 3 PVs.

Re: [linux-lvm] A hint on a process

[Marek Podmaka]

Hello,

Tuesday, December 7, 2010, 2:13:35, Stuart D Gathman wrote:

> Your method will fail because the raid superblock is at the end of the
> partition.

I think it should be possible - just create bigger partition on the
bigger drive, synchronize, replace 2nd drive (also with bigger
partition), synchronize and then use mdadm --grow, which should grow
the md1 device to the full partition size. Then pvresize to resize the
PV inside VG and use can use the extra space.

-- 
  bYE, Marki

Re: [linux-lvm] A hint on a process

[georges.giralt]

Hello !
Thank you both for your answer.
Marek, I've checked the grow mdadm option.
Here is what the manpage said about it :
       "Normally  when  an array is built the "size" it taken from the smallest
       of the drives.  If all the small drives in an  arrays  are,  one  at  a
       time,  removed  and replaced with larger drives, then you could have an
       array of  large  drives  with  only  a  small  amount  used.   In  this
       situation,  changing  the  "size" with "GROW" mode will allow the extra
       space to start being used.  If the size is increased  in  this  way,  a
       "resync" process will start to make sure the new parts of the array are
       synchronised.

       Note that when an array changes size, any file system that may be stored
       in  the  array  will  not  automatically  grow  to  use the space.  The
       filesystem will need to be explicitly told to use the extra space."
So if my kernel revision support it, I should change one disc at a time, with the 2 bigger disks,
wait for synchronization after every change, then ask the array to grow to reach the disks boundaries (I'll make the second partition up to the physical end of the disk).
If everything works, I just have to pvresize the above PV to get the extra space available...
If something goes south, I will still have the original 160GB disk available to start again, I hope (I do not know what exactly does the mdadm --fail command on the actual disk and data...).
I would greatly appreciate a comment from a person actually having dealt with such issues ;-)
I know I'm some sort of a coward here..... But I would not like loosing data ~:-)
Thanks !
----- Mail Original -----
De: "Marek Podmaka" <marki@marki-online.net>
À: "LVM general discussion and development" <linux-lvm@redhat.com>
Envoyé: Mardi 7 Décembre 2010 08h31:34 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne
Objet: Re: [linux-lvm] A hint on a process

Hello,

Tuesday, December 7, 2010, 2:13:35, Stuart D Gathman wrote:

> Your method will fail because the raid superblock is at the end of the
> partition.

I think it should be possible - just create bigger partition on the
bigger drive, synchronize, replace 2nd drive (also with bigger
partition), synchronize and then use mdadm --grow, which should grow
the md1 device to the full partition size. Then pvresize to resize the
PV inside VG and use can use the extra space.

-- 
  bYE, Marki


_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

Re: [linux-lvm] A hint on a process

[Georges Giralt]

Hello !
Here I am again.
The migration went well. Here is a synopsis of what I've done (including
finding a second drive with lot of SMART errors...)
Bought 2 SATA 320G disks (different make/model...)
Make a set of backups of every partitions on the machine. Check the dump
are readable and stored in a safe place ;-)
Remove one failed 160 GB disk from raid 1 array (software raid, with 3
disks.)
Physically replace the disk with one 320 GB disk. Partition the new disk
to have the small partition for /boot identical as it is on the previous
disk, allocate the remaining space to the second partition. toggle them
both to raid autodetect.

Add each partition to the two arrays. Wait for synchronisation. 
Repeat for the two other disks.
When done, you've a raid array saying that it's size is 150 GB and this
on a roughly 320 GB partition.
Do a mdadm /dev/md1 --grow --size=max on the offending array, wait for
the synchronisation to take place, and when done do a pvresize /dev/md1.
Et voila, you're done. You've got a 320GB PV based on a RAID 1 device...
Many thanks for your help !

P.S. : I'm a bit paranoid and know my wife will forgot to tell me that
the computer said "something funny this morning" so I build my arrays
with 3 disk for a mirror...
Having been bitten by a bad disk lot, which make me loose all my data
because all disks died in a couple of hours, I build my arrays with
mixed brands/models to avoid this. I loose a couple of sectors here and
here but, IMHO it is worth it....
Le 07/12/2010 02:13, Stuart D Gathman a �crit :
> On 12/06/2010 05:36 PM, Georges Giralt wrote:
>> Hello !
>> I've a system (now on Ubuntu 9.04, but initially on a Fedora ) set up as
>> follow :
>> There are two RAID1 software raid arrays (md0 , which is around 100 Mb
>> and holding an Ext2 FS for use in booting, md1 occupying the rest of the
>> space used as a PV for LVM) made on a couple of old 160 GB disks.
>>
>> On the LVM VG0 are a lot of LV onto which Ubuntu is installed.
>>
>> One of the two disks failed. I can't find a 160 GB replacement. Only 320
>> Gb for the smallest availlable disk near where I live.
>>
>> So I plan to move the system to 320 GB disks and, if possible, not
>> wasting the 320-160 difference....
>> The process I thought about is as follow :
>>
>> 1) insert one 320 disk in both arrays (after partitioning it correctly,
>> 100 Mb for the first partition and the remaining for the second.)
>>
>> 2) wait for the raid1 to synchronize.
>>
>> 3) mark the remaining 160 GB disk as failed and remove/replace with
>> another 320 GB disk set up as the first.
>>
>> 4) wait for the arrays to reconstruct/synchronize.
>>
>> 5) Extend the PV my Volume Group is build on (md1 in this case)
>>
>> 6) enjoy a beer...
>>
>> What do you think of my method ? Is it a good one or am I missing
>> something ? You will have understood that losing data is not an option ...
>> Many thanks in advance for your answers, critics and pointers...
>> Regards.
> Your method will fail because the raid superblock is at the end of the
> partition.
>
> I use and recommend this variation:
>
> 1. Replace 160 with 320, allocate 2 partitions to match (or slightly
> exceed if geometry requires) the partitions on
> the 160.  Synchronize. 
>
> 2. Replace the 2nd 160, resynchronize. 
>
> 3. Add a 3rd raid1 with the remaining space, and extend the VG with the
> additional PV.
>
> If your system can support 3 drives, you can always partition to mirror
> everything despite size mismatches.  For example,
> step 3 would become:
>
> 3a. reinstall the 160 and allocate 2 80g partitions on the 160 (which is
> no longer the default boot drive).  Allocate an 80g partition on each
> 320 to mirror the 2 80g partitions giving md2 and md3.  Mirror the
> remaining 80g in each 320 for md4.  Extend the VG with the addition 3 PVs.
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>


-- 
If the only tool you have is a hammer, you tend to see every problem as a nail.
                Abraham Maslow
A British variant :
Any tool can serve as a hammer but a screwdriver makes the best chisel.