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

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

 



On 01Apr2009 19:42, jackson byers <byersjab@xxxxxxxxx> 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.

Cheers,
-- 
Cameron Simpson <cs@xxxxxxxxxx> DoD#743
http://www.cskk.ezoshosting.com/cs/

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@xxxxxxxxxxxxxxx>

-- 
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux