This is a possible duplicate of Moving files from one partition to another on an SSD
When I copy files from C:\...\Downloads\ to C:\...\Desktop\ it happens instantly, but if I copy the same file (1.12 GB) to D: it takes quite some time. Why so?
First, your core question is this:
Why copying takes time across partitions on the same disk?
Will go into detail below, but a single disk with multiple partitions is not “the same disk” from a filesystem perspective. From a filesystem perspective, a partition is simply another “physical disk” even if it is simply just a “logically” allocated space on a larger, parent physical disk where two paritions reside:
Read on for more details.
Note: I am using Linux/Unix/Mac OS X terminology since that is where my core expertise is, but the basic concept applies to Windows and really just any OS.
Why doesn’t the OS/kernel simply move the info. of bytes/sectors/address-pointers/whatever allocated to that file from one FileSystem table to other partition's FileSystem table?
This is because the inode table that controls & manages what sectors are connected to what files is a per-disk, per-partition construct.
So when you copy something from C: to C: all that is happening is an inode entry is being edited on the C: drive to indicate the new path to the file on the same C: drive.
But when you copy something from C: to D:, the data must be copied and a new inode entry must be created on the D: drive.
Let’s say you are wondering why not just keep all drive data on the main C: drive instead of doing it on a per device, per partition basis? Well, then what happens when that drive or partition is moved to another machine? The D: drive would just look like bare and unused space with out that allocation table data. And if the C: drive crashed in a scenario like this, not only do you lose the C: drive but also the deeper filesystem info connected to the D: drive.
You also edited your question to state this:
I suppose partitioning is logical not physical.
Yes and no. Partitioning is logical on the side of the partition table. But on a filesystem level, the filesystem sees a partition as if it were another physical disk.
And you also ask this:
So why doesn’t the OS or FileSystem controller simply copy this metadata about
helloKitty.txtto other partitions table?
It does copy the metadata from one place to another. But it also copies the actual file data since that data on D: won’t exist until it is copied from C:. And the metadata it copies is limited to the basics about the file contents since byte and sector data will change when it copied from the C: disk/partition to the D: disk/partition.
The byte’s pointers do not change, they are absolute because the partition is logical not physical.
The partition is “logical” in the context of a partition. The data stored in the filesystem on that partition is not “logical” in the context of data about individual files going up to the partition table. That is simply the way it is and partition—as defined by Wikipedia—is described as follows; emphasis is mine:
Disk partitioning is the act of dividing a hard disk drive (HDD) into multiple logical storage units referred to as partitions, to treat one physical disk drive as if it were multiple disks, so that a different file system can be used on each partition.
A filesystem is more than just addresses for each file’s contents. It also has to keep track of which parts of the partition are unallocated (“free space”), and how much free space is available in total. If the filesystem in partition C: were to store some file data within partition D:, it would have to first look into filesystem D:’s structures to find some free space, and would have to mark that space as allocated in filesystem D: so that the data won't be overwritten by another file created in D:. Later, when you delete the file that appears to be in filesystem C:, it would have to reach into filesystem D: again to mark that space as free.
Error-checking would be problematic: Normally, if there’s space that’s marked as allocated but not actually part of any file in the filesystem's directory structure, this is considered an error. A consistency checker (e.g. Windows chkdsk or Linux/Unix fdisk) will either mark the space as free, or create a file mapped to that space so that a human can examine the data and delete it manually. But if the data in question is actually part of a file in some other filesystem, this would result in the space being marked as free (either immediately, or when someone deletes the “recovered” file) while there’s still a file using it.
Safely allocating files across filesystem boundaries would require the two filesystems to be permanently “aware” of each other’s structures, to the extent that they might as well just be a single filesystem that spans multiple partitions. Some filesystems actually support that: See zfs and btrfs. These act like a sort of RAID built into the filesystem: They can make multiple partitions, even on multiple disks, appear as a single logical drive. But the partitions—and disks—are dependent on each other; you can’t just take one and use it by itself.
Different partitions are like different disks in this aspect.
The blocks for each partition are assigned contiguously, what you propose is that the disk automatically repartitions itself assigning the sectors that belong to a partition to another.
This approach would be very error prone, would degrade disk performance and would break other features like journaling .
