I find myself moving reasonably large amount of data (20+ GB) from one directory tree to other. Often times they are on the same filesystem but sometimes they are on different ones. I do cp just to preserve the original data just-in-case. Once the copy is done I delete the original data after verifying that the data has been copied alright. Sometimes I just do mv if I feel too lazy to clean original data afterwards. However, I am wondering, from purely technical point of view, which operation is more efficient? Why?

  • 2
    When moving data across filesystems, neither is more efficient - they're about the same. the cp,verify,rm strategy is safer because it is easier to recover from an unexpected error - e.g. the mv or cp failing partway through due to disk full error or (if the destination fs is a network share) the network going down, etc. With cp you still have your complete original data in its original directory structure. With mv you have some of your data in the original dir, some in the target dir, and re-merging them may be difficult (esp. if the target dir contains other data). – cas Apr 19 '16 at 7:56
  • 4
    BTW if cp fails before completion due to error, once you have resolved the error you can complete the cp from where it left off by using rsync. In fact, you can use rsync instead of cp right from the start. – cas Apr 19 '16 at 7:58

Technically, mv is not atomic when the source and destination are on different filesystems, it is actually cp + unlink(). So at first mv will copy the file and then call unlink() to remove the file from the directory's list of entries.

So in this case, AFAIU whether you cp and then rm (unlink()) or use mv directly is totally your personal preference.

Whereas while mv -ing within the same filesystem, you should use mv as its atomic within the same filesystem (calls rename()) so less overhead.

Thanks @muru and @psusi for the pointing out the FS dependent behavior.

  • 3
    (…across filesystems). In the same filesystem, it's atomic. – muru Apr 19 '16 at 1:40
  • 2
    More specifically, in the same filesystem it simply calls rename(). – psusi Apr 19 '16 at 2:01
  • @muru Didn't know that..thanks..edited.. – heemayl Apr 19 '16 at 2:12
  • 1
    @Viesturs Of course e.g. permission issue. – heemayl Dec 29 '17 at 12:46
  • 1
    @Viesturs Nope. – heemayl Dec 29 '17 at 12:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.