Split reply, to address a different part of the problem.
On 11/5/06, Tracy R Reed <[EMAIL PROTECTED]> wrote:
Christoph Maier wrote:
> Yesterday's installfest was a rather productive one for me ... I
> _bagged_ some extremely valuable advice about how to solve the
> partitioning issue in a very elegant way, with LVM for most of my hard
> drive.
I have been preaching the benefits of LVM for years now, ever since it
came to Linux. All of my personal machines and all of the machines I
have deployed in my company have LVM. I often hear the people who really
don't want to have to learn LVM complain that it isn't really needed on
a personal system. But I strongly disagree with this. You may not need
it now but you may sometime during the life of that machine and if you
don't install it now when you are getting started you are looking at a
complete reinstall down the road which you will eventually wish you had
avoided. Fortunately most distro's install with LVM by default now. With
LVM and the new virtualization technologies I think the days of complete
OS reinstalls are behind us. Nowadays I reinstall a new OS beside the
old one in a logical volume on disk and often even run the two side by
side using Xen.
I had a failing drive (more and more bad sectors appearing) in my
mirrored pair of 250G drives. I want to add another drive to this anyway
and make it a RAID5. And I want to do it without any reinstalls or
backup/restores. Although I do have a backup just in case. So I bought 2
new 250G drives, and a new 500G drive. $300 for it all but my data is
worth it.
I shut down, plugged the 500G drive into my SATA bus, booted up (all
shutdown/startup steps in this process can been avoided with a hot-swap
chassis but I'm not going to invest in something like that for home use
but I do have it in my work-critical production machines since they are
the money makers), made a small /boot partition on it and installed
grub, made another huge partition and initialized it as a physical
volume, and added it to the same volume group as the mirror pair. Then,
on the fly with all services running, I did a pvmove and told LVM to
move everything off of the md0 (mirrored pair device) onto /dev/sdc (the
500G drive). Worked perfectly. Took an hour to move all the data though.
Then I shut down, swapped the failing drive for a good one and added the
additional 250G drive. Then I booted back up, told the BIOS to boot from
the 500G drive, had to change some of the grub boot options at the GRUB
command line because my root had moved. When GRUB first came along I was
skeptical and stuck with LILO but I now that I have learned it I realize
that it is FAR more flexible and powerful and would never advocate LILO
again. Then I booted from the 500G. I re-initialized the three 250G
drives as a RAID5 array, initialized the new md0 as an LVM physical
volume with pvinit, made it part of my volume group, and pvmove'd my
data back over. Then I split the 500G drive back out of the volume group
and put it into its own volume group.
Let me describe my current disk setup and ask for advice on expanding
it. I have a small Dell server with two SATA ports on the motherboard
(also the usual two PATA). Mounting space for only two hard drives.
Current OS is FC3.
Presently I have two PATA drives with SATA dongles, each with mostly
LVM partitioning. One disk 160GB "system" contains a real root (/)
partition and the rest is a Volume Group with several LVs. The other
disk 200GB "data" is another Volume Group with a couple of LVs. I
would like to expand the storage by substituting two 300GB disk
drives, both of which are SATA.
A brute-force approach would be to take out both old disks, and
install the two new ones, make a fresh installation of FC6 with LVM,
being careful to avoid the default Fedora partitioning. I can then at
leisure put the old disks into USB or Firewire boxes and migrate
everything back to the new drives.
Alternatively, I could migrate the data one drive at a time, which
would mean more opening and closing of the system box. I'm not sure
whether this would increase or decrease the down time, which is not
terribly important since this system is just my way of keeping busy in
retirement. :-)
carl
--
carl lowenstein marine physical lab u.c. san diego
[EMAIL PROTECTED]
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
