* Re: [linux-lvm] A hint on a process [not found] <1728359014.3510561291714776589.JavaMail.root@zimbra44-e7.priv.proxad.net> @ 2010-12-07 9:41 ` georges.giralt 0 siblings, 0 replies; 5+ messages in thread From: georges.giralt @ 2010-12-07 9:41 UTC (permalink / raw) To: Marek Podmaka, LVM general discussion and development 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/ ^ permalink raw reply [flat|nested] 5+ messages in thread
* [linux-lvm] A hint on a process
@ 2010-12-06 22:36 Georges Giralt
2010-12-07 1:13 ` Stuart D Gathman
0 siblings, 1 reply; 5+ messages in thread
From: Georges Giralt @ 2010-12-06 22:36 UTC (permalink / raw)
To: LVM general discussion and development
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.
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [linux-lvm] A hint on a process 2010-12-06 22:36 Georges Giralt @ 2010-12-07 1:13 ` Stuart D Gathman 2010-12-07 7:31 ` Marek Podmaka 2010-12-12 13:20 ` Georges Giralt 0 siblings, 2 replies; 5+ messages in thread From: Stuart D Gathman @ 2010-12-07 1:13 UTC (permalink / raw) To: linux-lvm 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [linux-lvm] A hint on a process 2010-12-07 1:13 ` Stuart D Gathman @ 2010-12-07 7:31 ` Marek Podmaka 2010-12-12 13:20 ` Georges Giralt 1 sibling, 0 replies; 5+ messages in thread From: Marek Podmaka @ 2010-12-07 7:31 UTC (permalink / raw) To: LVM general discussion and development 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [linux-lvm] A hint on a process 2010-12-07 1:13 ` Stuart D Gathman 2010-12-07 7:31 ` Marek Podmaka @ 2010-12-12 13:20 ` Georges Giralt 1 sibling, 0 replies; 5+ messages in thread From: Georges Giralt @ 2010-12-12 13:20 UTC (permalink / raw) To: linux-lvm 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2010-12-12 13:20 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <1728359014.3510561291714776589.JavaMail.root@zimbra44-e7.priv.proxad.net>
2010-12-07 9:41 ` [linux-lvm] A hint on a process georges.giralt
2010-12-06 22:36 Georges Giralt
2010-12-07 1:13 ` Stuart D Gathman
2010-12-07 7:31 ` Marek Podmaka
2010-12-12 13:20 ` Georges Giralt
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).