Short answer: fragmentation is drive specific and it is not preserved across a copy.
In fact, if done in the right way, a copy can actually be one way to defragment a drive.
Let me explain why that’s so.
Become a Patron of Ask Leo! and go ad-free!
Fragmentation is about the destination
If you have a highly fragmented file and you’re copying it to another drive that is not fragmented then it’s very likely that the file will also not be fragmented.
Fragmentation happens when the file is written, and is thus dependent on the characteristics of the destination drive.
As the file is being written it’s broken into “chunks”, and those chunks are then placed wherever there’s room on the destination drive. The operating system looks to find room on the disk to place each chunk. On a highly fragmented disk it’s often the case that a few chunks of the file goes here, a few go there, a a few more go over there, and so on. The result is that the chunks are scattered all over the disk; in other words: a fragmented file.
On the other hand on a disk that’s not very fragmented at all, then typically, the chunks can all be placed next to each other, one after the other. On other words a not-fragmented or “contiguous” file.
But it had nothing to do with where the file came from, it’s all about the disk that the file is being written to.
Nit: it’s really about free space fragmentation
I’ve been talking about “the disk” being fragmented, but in reality what matters with a file being copied in is only the fragmentation of the free space on the disk. It doesn’t really matter how fragmented the existing files are. If the “holes” that the “chunks” of our copied file will be written to are all scattered, the result is a fragmented file.
It is actually possible to have a disk with highly fragmented existing files, yet with a fairly large contiguous free space.
It’s just very rare. In most cases if the files on the disk are highly fragmented, then so is the free space. Thus it’s easier to talk about “the disk” being fragmented or not.
Copy: the poor mans’s defragger
Let’s take our example to an extreme.
We often defragment our hard drives, and we pretty much understand how that works. A little piece of software goes in there and basically shuffles all the chunks of the various files around so that they’re laying next to each other contiguously. The result is a defragemented disk.
Another approach that’s even sometimes faster (if you’ve got the hardware and the space to do it) is this:
- Copy absolutely everything off your your hard drive a simple file copy operation to some other drive. External disks are handy for this.
- Erase the first hard drive. The quick technique is to format it, but in reality any approach that removes everything will do.
- Copy everything back.
You now have a defragmented drive.
The “trick” is simply this: an empty drive is by definition a defragmented drive because there simply aren’t any “chunks” of files at all. As you copy files back to the drive the chunks are laid out contiguously since there are no pre-existing files to work around. The net result is a completely defragmented drive. (Caution: this assumes files are copied one at a time. Accelerators that try to copy several files at once can cause fragmentation as the copies compete for the free space on the drive.)
Sadly, this is difficult to perform on a system drive since Windows is running and has files open, and thus prevents those files from being copied. That’s why I stressed copying absolutely everything.
That, and the need for enough disk space to hold a copy of, are the biggest reasons you won’t see this technique being used very often.
There are copy programs with VSS, volume shadow copy service, that close any running file-like Windows–for a split second, copy it, and then release it. I’ve had a dozen programs running and made perfect, bootable copies to an external drive while the copy program works in the background.
Thanks for this article Mr. Leo.
I understood your article, but I have a doubt related to “write” priorization.
Assumption : I have many empty spaces on a disk (caused by files deletion) and a contiguous space too (a space that never had been used before),
– Where Windows will priorize to write a new file (a small and a big one) ?
Will Windows priorize to use the contiguous space existing in order to keep file’s performance or it’ll uses the first empty place ?
I know that’s a hard question because the SO can use both ways. But one of these processes has a priority to the other or not ?
Or in another words : which RULE Windows uses first ?
Thanks in advance.
Regards.
Marcos.
I don’t know. And I wouldn’t count on the answer if I did.
For one thing the rule, if there is one, isn’t imposed by Windows, but rather by the type of file system being used. Thus the answer might well be different for FAT32 versus NTFS file systems.
Secondly, the rule may well change over time – both in real time (the filesystem drivers could well take MANY different things into account that change in real time when deciding where to put data), or as the software is updated and algorithms are changed.
Bottom line: whatever the answer is I wouldn’t count on it too much.
I’ve tested this repeatedly from a drive that was HEAVILY fragmented to a drive that had absolutely zero fragmentation, and moved only one file that was in 6 fragments. Once on the new drive, I analyzed it and that file was still in 6 fragments. It will put it all more-or-less together but if the pieces are in the wrong order (IE instead of all pieces being a-b-c-d-e-f it copies in the order they were in on the source drive, b-d-a-c-f-e for example). So if you have a fragmented file and move or copy it to a new drive, it will be just as fragmented there.
There’s something else going on here. Copying to another drive should not copy fragmentation.
Firmware of the HD effects fragmentation. At least this is my experience. Very few hard drives receive a copy and not fragment it. The overwhelming majority, and perhaps all modern TB drives fragment data. Terabytes of data (from a defragmented drive) are heavily fragmented after xfer. I’ve tried multiple copy utilities, as well as 32 & 64 bit OS’s. WD, Seagate, Toshiba, Hitachi…This is an event which has bugged me for years… I suspect the HD makers consider this acceptable as they chase faster write speeds. Just to reiterate: copy from one fragmented drive to an empty or defragmented drive will not defragment the copied data 99.9% of the time. In fact, I’ve only had one drive with which it worked out of many dozens.
Fascinating. The exact opposite of my experience. Particularly since it’s not the firmware that controls how files are laid, but the operating system.