[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: using 'mv' instead of 'cp' to transfer directories to other partitions or disks

On 01Apr2009 19:42, jackson byers <byersjab gmail com> wrote:
| In another thread Re: shrinking reiserfs partitions, filesystems
| Roberto Ragusa responded
| > Do not forget another option: copy everything somewhere else
| > (external USB drive or something...), destroy the partition,
| > recreate it smaller, format and copy back.
| > In this way you get an implicit perfect defrag of your data,<<<<<<<<<<
| > which could be more or less useful, depending on the current
| > fragmentation of your filesystem.
| my question: isn't it true that use of 'mv' is much faster than 'cp' or
| rsync?
| ie to "copy everything somewhere else"
| instead
| "mv everything somewhere else"

Only within the one filesystem, because "mv" is just a series of renames
(and some directory creation if you're mving a tree).

>From one filesystem to another, mv is a copy followed by a delete.
Technically slightly slower.

| and
| instead of
| "..and copy back"
| do
| ".. mv back"

Same issue.

| Are there gotchas using 'mv' instead of the various copy tools?
| more fragmentation perhaps?

A "rename" style mv will change nothing, since the file data are not
being relaid on the disc; only names are changed.

But you _cannot_ "just" rename from one filesystem to another. The data
must be copied, and so the activity is the same as a "cp". And because
the data are copied, a new probably-not-very-fragmented file is made.

| I made one test case here  to test mv
| I first made a copy of /lib  to /libfc5copy
| and then tested mv on the latter to move it to my external usb
| mv libfc5copy /media/disk-1/mvlibfc5copy
| this seemed to complete in only a second or two.

That's probably because the copied data is still in RAM.
Copying to the USB, from the user's point of view, need only get
to the point of queuing the data to get to the USB drive.

You'd tested very little, really.

1: Use a bigger directory. Specificly, much bigger than your RAM.
2: Issue a "sync" command after the cp or mv.
   Only after that will the data be on the target volume.
   The sync time must be counted in your timing.
   A sync doesn't force the OS to _read_ from disc though.
   if you've read the data recently then the OS can just pull it from
   RAM, not disc, is it is still cached.

Anyway, a "mv" from one filesystem to another _is_ a "cp".
The timing is essentially the same.

Cameron Simpson <cs zip com au> DoD#743

Why do we want to mimic human intelligence? What possible use is a computer
that gets bored, gets horny, who doesn't feel like working right now, and who
doesn't know what to do with Sunday afternoon?
        - Tim Menzies <timm cse unsw edu au>

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]