27

Let's suppose I have a 2GB file that I want to move, and I have two hard drives that are exactly the same. Would it be faster to move the file from one drive to another, or will it be faster-moving the file inside the same drive?

I'm asking this because I suppose it will be faster transferring from one drive to another even though they are exactly the same, as you are performing a read operation on one drive and a write operation on another, instead of making a read/write operation on the same drive. Can someone answer this, and, if I'm correct, explain to me why more technically?

Thanks!

11
  • 54
    Moving is always faster on the same drive, copying is much slower on the same drive.
    – Moab
    Jun 15, 2021 at 18:53
  • 66
    Moving on the same drive rarely, if ever, actually moves the file data; usually, it just moves the entry in the directory. Jun 15, 2021 at 18:58
  • 19
    @Moab: moving from one drive letter to another drive letter will involve copying, even if it's the same physical drive. Jun 16, 2021 at 5:47
  • 10
    @JeffZeitlin: Only if it’s the same volume/partition.
    – Michael
    Jun 16, 2021 at 6:15
  • 6
    @Michael - Correct, if pedantic; most Windows users equate "drive" with "volume assigned a drive letter", even if there are multiple volumes/partitions on the same physical device. Jun 16, 2021 at 10:32

5 Answers 5

107

Moving a file inside the same partition (or same file-system) won't really move anything.

All it would do would be to delete its entry in the file-table and create another. The file itself will not be physically moved, so the operation will be almost instantaneous, no matter the size of the file.

13
  • 33
    I think this is true, except in some edge cases, such as moving a file on a ntfs formatted drive where one directory is compressed and/or encrypted and the other one isn’t. See for example here.
    – agtoever
    Jun 15, 2021 at 21:20
  • 14
    Suggested change: "the same partition" → "the same volume" since they are actually different.
    – iBug
    Jun 16, 2021 at 3:12
  • 5
    Even more interesting: Moving an entire directory tree with thousands of files is (when done right, OS dependent) just one entry. Moving (copy/delete) thousands of files between drives takes a while, even if the files are tiny. Jun 16, 2021 at 3:32
  • 1
    @pipe: in order to understand, you should know under which circumstances things will work the way you understood it and that there still might be circumstances when the answer might not apply. Sometimes you might think you have a drive and you're moving from that drive to the same drive, but in fact it's a WebDAV mapped network share or whatever and it suddenly behaves different. This will cause more confusion than a correct statement right away. Jun 16, 2021 at 7:44
  • 10
    @iBug the more universal way to put is probably "the same filesystem"
    – Tom Yan
    Jun 16, 2021 at 11:44
68

It depends on a bit more than just the physical hardware layout. In general, there are four cases to consider:

  1. Moving a file within a single filesystem (IOW, within a single ‘drive’ by the Windows definition of the term ‘drive’).
  2. Copying a file within a single filesystem.
  3. Moving or copying a file between two filesystems that are on the same physical storage device.
  4. Moving or copying a file between two filesystems that are on separate physical storage devices.

In general, the first case is always going to be the fastest, because short of some atypical situations, it just amounts to updating some of the filesystem metadata. The only two exceptions you would likely ever encounter are dealing with in-line data transformations (such as the in-line compression supported by NTfS) where the source and destination have different rules for such transformations, and dealing with certain networked filesystems (such as older versions of NFS), with both cases becoming equivalent to the third case.

The speed of the second case depends on the filesystem involved. If it supports reflinks (like ZFS and BTRFS do), then it can be just as fast as the first case (because it essentially becomes the first case). If it does not, then it will generally be equivalent to the third case instead.

The third case will usually be the slowest case, because the system has to read the data from the device, store it temporarily in RAM, and then write it back out to the device somewhere else. Some storage protocols may support ‘device-side copy’ functionality (some SCSI devices support this for example, as do most intelligent networked filesystem protocols), in which case this can potentially be rather fast, though usually still slower than the first case.

The fourth case is where things get really interesting, because it’s performance depends almost entirely on the specifics of the hardware setup of the physical storage devices. Some easy examples of this:

  • In a classic PATA setup with both storage devices on the same cable, the performance is actually marginally worse than the third case. This is because you have a single data path shared by both devices, and on top of the read/write cycle you would normally have for the same device, you end up with some extra overhead just for managing the two devices at the same time.
  • In a relatively standard SATA setup with both storage devices on the same AHCI SATA controller, performance will be significantly better than the third case, but still nowhere near peak device bandwidth. This is largely due to limitations in the AHCI spec that make it at best challenging to handle multiple devices simultaneously on a single controller (the implications are not bad enough to make it a problem for consumer usage, but are part of the reason that SCSI still reigns supreme in enterprise usage).
  • With a typical enterprise SAS setup, the performance will be relatively close to the peak bandwidth of the slower of the two devices, provided it’s the only thing running at the time. SAS is quite simply exponentially more efficient than SATA.
  • With a pair of very nice NVMe devices, just the right hardware layout on the mainboard, and proper support in the OS, 99% of the transfer can actually run at peak bandwidth of the slower of the two devices. This setup is hard to put together, but allows you to leverage a little-used feature of PCI-e that allows two devices to transfer data directly without needing to bother the host.
12
  • 6
    @RossPresser Yes, at that time I would have been surprised if a network share was slower than a floppy disk. 10Mbps, even factoring in protocol overhead, is blazing fast compared to the roughly 240 kbps transfer speeds that a 3.5 inch floppy drive could do. It’s possible in modern times to similarly have faster copies between network shares than local disks, but it’s atypical outside of an enterprise setting (because your home file server’s storage stack is almost certainly no faster than what you have on the client system). Jun 16, 2021 at 17:06
  • 2
    With asset streaming being introduced in games, with hardware support in GPUs, one would hope that P2P DMA in PCIe would have relatively fast improvements in support, both in Windows and in NVMe drives. So what was little-used a few years back, has come to the fore.
    – jaskij
    Jun 16, 2021 at 18:33
  • 7
    Also note that 3rd case will be much slower than 4th case when we're talking of rotating media as HDDs (as opposed to SSDs), due to having to seek all the time, killing performance. Jun 16, 2021 at 19:49
  • 1
    Case 4 - two PATA drives on a single cable will normally be faster than the case 3. Normal PATA drives use a write-back cache (receive the sector content and write it to the disk later) and read-ahead (read the following sectors ahead so their data will be then available immediately). --- Unfortunately I do not know if the classic ATA (without TCQ) allows to send a command, free the bus and finish the command later. This would make an additional help to optimize operations of two drives on a single bus. Jun 18, 2021 at 9:23
  • 3
    @PeterCordes In general yes, that’s correct. And if you’re running a true bulk sequential transfer (like cloning a disk), you generally won’t have any issues with AHCI and SATA hard drives. Copying files is pretty consistently not like that though, unless you’re only copying a few very big files. There are a lot of associated metadata reads and writes, (hopefully) proper write barriers, and the files are generally not going to all be in one place in the right order, so you have latency in multiple places affecting your throughput simultaneously, which makes the AHCI overhead worse. Jun 18, 2021 at 13:03
6

tldr: Moving from one drive to another drive can be faster, especially with rotational storage!

What really matters isn't if the move is staying within the same drive. What matters is if the move is staying within the same filesystem.

This is more correct than referring to partitions as do some comments. (Take for example an lvm partition with two LVs in it. Same penalty moving between them as would be between two partitions.)

This pedantry is rather important: Drive, Partition, Filesystem, are not interchangeable despite most people taking that for granted.

There is no spoon:

Moves aren't what you think they are, inside a filesystem. In fact, the notion of physical location, inside a filesystem, is false. The whole hierarchical structure is much a facade put on to help us humans visualize things. You should think of all files within a filesystem as randomly numbered objects in a database table. One of the fields in that table is the random number, another is the data itself, another permissions, and one is the full file path.

Moving a file then is just as simple as updating the tiny field that says the path to that file. And that's what it is in most filesystems.

"Compressed Dirs" and "Encrypted Dirs" add more I/O to a move. As could BTRFS subvolumes, and some other trick features. But generally this is how a move works in most filesystems.

Once you move a file from one filesystem to another filesystem however, the entirety of that file's contents have to be read and written to disk. And if you have two disks to share that IO load it will be much faster. Especially considering all the head movement in a rotational drive.

0

Edit: it seems this is no longer true, thanks @briantist.

The answers above are spot on, but there's an important point to know about how windows handles file permissions that was not mentioned.

If you 'move' a file in the same filesystem from one folder to another that have different permissions, the 'moved' file will NOT automatically inherit the permissions of the new parent folder. e.g. if an admin moves a file from one user's profile to another, the other user will likely not be able to access the file.

If you are moving small amounts of data it's often easier to just copy and then delete the source, if you are dealing with lots of data there are ways to fix the permissions after the move (https://serverfault.com/a/537564)

1
  • This only applies to Windows XP, the very first sentence of that question say that Windows 7 and up are not affected: When XP clients move files on the same volume, the permissions are moved with it. With Windows 7 clients and up, when a file is moved, the permissions are inherited.
    – briantist
    Jul 3, 2021 at 2:07
-2

I think moving files from one hard drive disk to other drives is faster because if we want to move several different files to one drive, it is slower due to several events such as fragmentation of files in different parts of the drive and to solve this problem, the drive must be defragmented.

See this image: The disk defragmentation in Windows XP

2
  • 1
    Please read other answers before posting your own. That will not only let you avoid repeating what others have already said, but may also clear up some misconceptions of yours.
    – gronostaj
    Jul 1, 2021 at 8:30
  • Well, but I wanted to point this way in another direction to help others.
    – CHP
    Jul 1, 2021 at 8:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .