Migrate OS to smaller drive?
in [Debian]
|
From: Ron Johnson on 11 Apr 2010 11:00 On 2010-04-11 08:11, Clive McBarton wrote: > > Sjoerd Hardeman wrote: >> mount the new device (mount -odev /dev/newdevice), and do a >> rsync -ax / /media/newdevice. > > What exactly is the advantage of this approach over "cp -a" or "mv"? > > I would have suggested mv. It has the useful property that you can > easily spot aborted transfers by the fact that the original device is > not empty afterwards. One note is that I've had issues where symlinks remain pointing to the old drive. (That was a long time ago, though, and maybe I did something wrong.) tar might also work, given the appropriate flags. -- Dissent is patriotic, remember? -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/4BC1E301.8020105(a)cox.net
From: Ron Johnson on 11 Apr 2010 11:10 On 2010-04-11 08:29, Clive McBarton wrote: > > Eduardo M KALINOWSKI wrote: >>>> mount the new device (mount -odev /dev/newdevice), and do a >>>> rsync -ax / /media/newdevice. >>>> >>> What exactly is the advantage of this approach over "cp -a" or "mv"? >>> >> Over mv? That you keep the original files. > > Of course. But in this case the OP said "migrate". Ooooo. Remind me never to have you work on my computer. Never destroy the original until you know the copy works! >> Over cp? That you can resume from where you left off in case the >> transfer is stopped for any reason. > > Useful point. With cp you'd have to start over. > > What are the disadvantages of rsync? E.g., doesn't it compress and > decompress everything, Only if you want it to. > hence hogging the CPU You won't be doing anything else at the time... > and possibly slowing transfers? Hah. Speeding up transfers is more likely, since the wire is always the bottleneck, and compression means it will be carrying "more bits per bit". -- Dissent is patriotic, remember? -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/4BC1E472.8060202(a)cox.net
From: thib on 11 Apr 2010 15:50 Others suggested using filesystem-level tools, which is really fine. Alternatively, you can shrink the filesystem and move the entire block at once. Each method probably has its pros and cons. -thib -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/4BC22782.8060907(a)stammed.net
From: Sjoerd Hardeman on 11 Apr 2010 17:00 Ron Johnson schreef: > On 2010-04-11 08:11, Clive McBarton wrote: >> >> Sjoerd Hardeman wrote: >>> mount the new device (mount -odev /dev/newdevice), and do a >>> rsync -ax / /media/newdevice. >> >> What exactly is the advantage of this approach over "cp -a" or "mv"? >> >> I would have suggested mv. It has the useful property that you can >> easily spot aborted transfers by the fact that the original device is >> not empty afterwards. > > One note is that I've had issues where symlinks remain pointing to the > old drive. (That was a long time ago, though, and maybe I did something > wrong.) I thought symlinks keep point via a file location memo, like "look at /usr/share/the/file/you/want", which is the old location just after copying, but the new location when you boot from your new device and that becomes root. Sjoerd
From: Clive McBarton on 11 Apr 2010 17:00 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ron Johnson wrote: >Never destroy the original until you know the copy works! In my earlier days I would have avoided mv for exactly that reason. But when copying (including rsync), you cannot easily see that it worked from the emptyness of the original file system. And comparing large filesystem trees (not just 4GB as in this case) is trickier than most people realize. At least a simple "diff -r" will be far from doing it. Maybe you have some good way of comparing FS trees? >> hence hogging the CPU > > You won't be doing anything else at the time... The OP didn't say that. Maybe you would do it that way. Maybe me too. Not that it matters once compression is disabled. >> and possibly slowing >> transfers? > > Hah. Speeding up transfers is more likely, since the wire is always the > bottleneck, and compression means it will be carrying "more bits per bit". There's no mention of wire transfer anywhere in this thread, and in fact for most people the upload of >4GB would be too much anyway. I presume he has both drives build into the same computer. Note that he talks about migrating / . Cases of remote transfer (transferring / to a remote machine, which must hence already have a / ) are theoretically possible but probably not relevant here. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkvCNrwACgkQ+VSRxYk440/d8wCgkOhMNQfa7OTWUEtcdCKJ5mdr H20AoNgy5CYLmTdy1Ki1DK4dj58uIe/r =CzO1 -----END PGP SIGNATURE----- -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/4BC236BC.1050004(a)web.de
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 5 Prev: What prevents mounting of USB devices? Next: Want it? Give |