Carl Lowenstein wrote:
On Dec 10, 2007 5:14 PM, SJS <[EMAIL PROTECTED]> wrote:
begin quoting Gus Wirth as of Mon, Dec 10, 2007 at 02:09:49PM -0800:
SJS wrote:
Hm...
Let's say I have 3 disks and 1 CDROM drive and two IDE channels.
I want to upgrade one of the disks.
So... without LVM, it's simple. I pull the CDROM, drop in the disk,
partition, format, mount, and play with tar or rsync, modify fstab,
pull the old disk, move the new disk, reconnect the CDROM, and bob's
your uncle.
Yep, that's the way I commonly do it if I want to replace an existing
physical drive with another (presumably larger) one.
With LVM, is it even simpler?
Well, for me in these types of upgrades, fiddling with the hardware
rather than learning esoteric software has always been the more
expedient path.
Yes. But you have to have empty space beforehand to allocate. Or you
have to do some gyrations to shrink a filesystem that has excess space
in order to reallocate it to the filesystem that needs it. Answers at
<http://www.tldp.org/HOWTO/LVM-HOWTO/index.html>
Specifically,
New hard drives are so cheap (and older spare ones usually abundant, if
needed) that I figure "Why bother with those kind of gymnastics?". I
just move the physical drive's contents to another of the needed size
and be done with it. It's not like I won't be able to use that old drive
(someone always needs more room in their hand-me-down system).
...although it seems to require my changing where the CD-ROM drive
connects into the IDE chain(s). I would not consider this a _good_
solution to the single most common disk-space problem I've ever had.
I guess I don't follow - you need the CD-ROM to run a Live-CD? If I am
moving data to another physical drive, the CD-ROM drive temporarily
gives up a needed connector on the data cable, to which it is returned
after the copy-swap process. I don't remember having problems just
copying data to another drive from a running system. If necessary, I'll
back it up to my file server as the intermediate medium.
That's only if you don't have another place to connect the extra drive.
It's rare that I can just _add_ disk; most often, I need to replace
a disk with a bigger one, on a system that has no room for new devices
or spare disk.
So I think it's "no, it's not simpler", rather than "yes, it is simpler".
Hm. Given TWO disks, it might be simpler. Connect spare disk #1, pvmove
everything off the disk-to-be-replaced, vgreduce out the disk-to-be-replaced,
pull disk-to-be-replaced, connect spare disk #2, pvmove everything off of spare
disk #1 on to spare disk #2, vgreduce out spare disk #1, and you're done with
nary a tar nor rsync in sight.
That's THREE disks, right (Spare #1, Spare #2, and Disk-to-be-replaced)?
Why bother with Spare #2? Just copy the data to Spare #1 (really a
replacement disk), swap disks, and be done with it?
Although tar or rsync might be faster than all that pvmoving.
(And if you're backing up everything anyway... would restoring be faster?)
It seems to me that the above gyrations are logically equivalent to
the classic approach:
1) Dump from old drive to intermediate storage medium.
2) Restore to new drive from intermediate storage.
I seem to remember something like this from 6th Edition Unix in a
discussion of how to increase the size of a file system.
Of course nowadays the intermediate storage would be another disk
drive rather than magtape.
carl
As I usually do, if needed. If the computer can handle the new drive
being physically connected (i.e. has spare data and power connectors)
then I don't need an intermediate medium. The new drive does not really
have to be bolted in - I just use an old anti-static shipping envelope
to insulate the drive while it's temporarily connected and lying
somewhere inside or outside the box. Of course, with a laptop, it's
obviously a bit trickier.
Usually the intermediate medium is my fileserver. Not fast, but now that
my LAN is all Gigabit, fast enough for a home system. If needed, I just
run it overnight, and log the copy or rsync output to a file somewhere
so I can check to see if everything copied okay.
--
Best Regards,
~DJA.
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
