What does disk defragmenting do?

[rcgldr]

Even with an SSD, random access does have an effect on performance, specs from an example SDD: 415MB/s Sequential Read, up to 175MB/s Sequential Write and 35K IOPS for Random 4k Read . That 35K IOPS for a random 4KB read translates into 140MB/s transfer rate.

I believe you may be confusing two completely different problems here.

This could be related to the high speed ram cache, common with many SSD devices, allowing them to "read ahead" in anticipation of sequential reads, and/or it could be related to the amount of data transferred per command, but the stated specs for don't specify the transfer size per IOP (command) used to produce the sequential read transfer rate.

runs the TRIM command on the (SSD) drive ...

For those that don't know about TRIM, wiki article:

http://en.wikipedia.org/wiki/TRIM

 

[Square1]

See if you have any large specific file intensive task that you actually regularly do and which doesn't require finger input while running. Save your original data. Time the task with a stopwatch. Defrag your drive. Then time the task on the original data again. Then please, please, post the results here.

Do you have particular applications in mind? I haven't defragged in a while and I was hoping to do it this weekend. Keep it simple though I am not super tech literate.

 

[jim mcnamara]

Why has no one mentioned disk latency?

This is usually measured in seek time and rotational latency. For physically spinning disks.

Seek time is the time required to move the disk head to a particular position. Rotational latency is the time it takes for the disk platter to spin to the required position to allow the head to access a disk sector.

SSD's are NOT physical disks. They do not have latency related to the problem of getting the read/write head in the correct physical location on a spinning disk to access a file. And the latency SSD's do have is two orders of magnitude better than physical disk latencies. They are on the order of 1/50000 s. Expensive physical disks have latencies in the 2+ milliseconds range.

Fragmentation is something that affects how a file is physically laid out on a rotating disk. The sector(s) it lives in. If disks are fragmented, then the disk hardware has to "mess around" getting multiple distant sectors under the read/write head. Many seeks can be required to access a file sequentially. Not so an SSD.

Modern disks are much less debilitated by fragmentation. Rotational latency on a SATA III disk at 15000rpm is now miniscule compared to comparable high end drives from the 1990's. Multihead disks reduce seek times.

Plus. Disk controllers cache disk data in controller memory and modern OSes cache file inodes (metadata) plus disk data too in RAM. When a file is opened, with the first read request a large part of the file is read in. My Compellent SAN has a MINIMUM read of 2MB. Solaris is tuned to keep ~100% of inodes since boot in RAM. This is for 100K files.

This explains the comment about "You generally do not need to defrag modern disks".

As aleph zero explained, getting meaningful I/O data and relating it to performance can be trying. And not always fruitful. This is due in part to the obfuscation of real I/O throughput effects by things like the caching I mentioned.

 

[rcgldr]

For both hard drives and SSD's, fragmentation forces the operating system to split up a large read request into multiple commands to handle each fragment. If the fragments are large enough so that command overhead is relatively small, then fragmentation only an issue for hard drives because of the latency as mentioned.

In my case, I perform backups of hard drive partitions using a program that does a file / folder copy of a partition to a folder on another hard drive. I follow this up with a file / folder verify. For restores, I do a quick format (and restore the volume serial number), then copy from folder back to partition and do another verify. The performance of this backup is affected by fragmentation and file ordering, since the program copies files in a fixed order, the directory tree order (all files in a directory copied in one group before handling any sub-directories in a directory). This process is significantly sped up after the first backup / format / restore, since future backups will be nearly all streaming I/O.

Some (or most?) SSD's use internal remapping of data, so what may seem like a defragemented file is still "fragmented" in the SSD's internal mapping. I don't know if a a backup / format / TRIM / restore cycle would "defragment" the internal memory of an SSD or if that would be of any benefit, since a SSD may have an algorithm to equalize usage of it's internal memory via it's internal remapping of 4k clusters.

 

[HowlerMonkey]

Back when hard drives were slow, we made our own custom interleaving to suit our application in the interest of lower latency.

Haven't done it in at least 15 years.

 

[cjl]

Modern disks are much less debilitated by fragmentation. Rotational latency on a SATA III disk at 15000rpm is now miniscule compared to comparable high end drives from the 1990's. Multihead disks reduce seek times.

Interestingly enough, this simply isn't true.

First of all, modern SATA disk drives run at 5400-7200 RPM. A few (the WD Velociraptor series) run at 10,000 RPM. None run at 15000 RPM (15k drives do exist, but they run on a SAS interface rather than SATA, and are pretty much exclusively for enterprise use). Multihead makes no difference to seek time (just look at the seek times for drives of differing capacity that are the same generation - most modern 500GB drives are 1-2 head, while 2TB drives have 4-8 heads). Most modern hard drives have a total access time on the order of 12-18 milliseconds, with the very best consumer drives (the WD Velociraptors mentioned above) getting as low as 7ms or so. The Quantum Fireball EX drive from 1998 (available in capacities up to 12 GB!) had an access time of around 16 milliseconds. Yes, the better modern drives are closer to 12ms, but that's hardly miniscule by comparison.

The bigger factor in why modern drives don't need to be defragged as much is a combination of 2 factors. First, hard drives have a much larger cache and systems have much more RAM. As a result, much more user data is cached, and this somewhat isolates the user from the direct performance impact of the disk itself. Second, the operating system is much more intelligent about how it places data - Windows 7 is much better about preventing fragmentation in the first place, whereas Windows 95 or 98 was much more simplistic in its methods of drive access.

 

[harborsparrow]

I have found that there is one case in which it is very useful to defragment Windows machines, and that is immediately after they are installed. Once this initial defrag is done, then blow up the swap file (in the Control Panel options--message me if you want to know how) so that it is already at its maximum size (set the minimum and maximum size of the swap file to the maximum recommended size.). This avoids having the swap file shrink and grow over the years. Providing one large, contiguous allocation for the (invisible to most users) swap file used by the operating system will save you the pain of the system eventually slowing down if the swap file gets broken into multiple pieces that lie far from each other on the disk.

This is especially true if the operating system (and all the files on it) take up a large percentage of the drive.

I've studied computer architecture and memory systems at great length over the years, and I've had a ton of practice with this, and I think this holds even for SDD's--getting that one large allocation for the swap file will help Windows stay tuned up.

Other than this, I doubt it's all that important to defrag the more modern systems even if they have moveable drive parts, because the disks are typically huge as compared with the amount of files on them, which means the drive will just keep allocating new, unfragmented space for a darn long time. Besides, most Windows systems these days will defrag automatically (if you don't stop them) in the background when you are not using the machine. Usually, I tell Windows not to defrag on a schedule or at will, and I do it myself once in a while (usually while watching a ballgame or overnight).