Re: using 'mv' instead of 'cp' to transfer directories to other partitions or disks
Aaron Konstam wrote: > If you are using mv to > transfer to a different disk or partition it probably a little slower. Right. Because mv from one partition to another is: cp + delete src. And this is slower than just cp, but only slightly since marking a file deleted is very fast. Matt Flaschen -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: using 'mv' instead of 'cp' to transfer directories to other partitions or disks
Cameron Simpson's response was like getting a complete tutorial! thanks very much! Jack -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: using 'mv' instead of 'cp' to transfer directories to other partitions or disks
On Wed, 2009-04-01 at 19:42 -0700, jackson byers wrote: > - > 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" > and > instead of > "..and copy back" > do > ".. mv back" mv is faster if you are on the same partition since the data is not moved just the pointer to the data is changed. If you are using mv to transfer to a different disk or partition it probably a little slower. -- === Everything ends badly. Otherwise it wouldn't end. === Aaron Konstam telephone: (210) 656-0355 e-mail: akons...@sbcglobal.net -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: using 'mv' instead of 'cp' to transfer directories to other partitions or disks
On 01Apr2009 19:42, jackson byers 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 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 -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
using 'mv' instead of 'cp' to transfer directories to other partitions or disks
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" and instead of "..and copy back" do ".. mv back" Are there gotchas using 'mv' instead of the various copy tools? more fragmentation perhaps? 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. Of course this is only useful if you want to erase the original. thanks for any advice Jack -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
