Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I don't understand how defragmentation isn't an issue on SSDs.

It's mostly a filesystem problem, not a hardware problem.



There's a difference between something still existing and something still being a problem.

The reason it was a problem on spinning disks, was that the delay in getting the next bit of data highly depended on where it was relative to the previous bit. With SSDs (as I understand it) looking up any bit of data is (just about?) independent of where it is located.

So, it's still a thing - but the cure (involving lots of wear) is a lot worse than the disease now.


If you read data to an arbitrary position in a file, you first need to figure out in which block(s) that data is located.

If the file is fragmented, this may require more reads than if it's contiguous and uses an extent.

Exact scheme is filesystem-specific.


Yeah, that was one of the reasons I said "just about". But minuscule compared to millisecond seek latencies on a spinning disk.

So the problem getting orders of magnitude smaller while the costs of the cure increasing a lot swung the equation away from defragging being a good thing overall.


Spinny hard drives have a master record file that tells the seek heads where all the parts of the data lie on the magnetic material.

It takes time for the read arms to move back and forth to literally read the data on the sector indicated by the master record file, and defragmenting the drive helped minimize that by moving the files around to be a linearly arranged as physically possible given the sophistication of the given system.

SSDs also have a similar master record file, indicating where all of the bits of the files are located on the flash memory in the hard drive, but since it makes at most the most atomically minute difference in seek times for the controller to read the data from those sectors (since there is no seek arm that has to physically move to the physical location nor any delay waiting for the spin of the disk to reach the correct location for the data read to begin) then file "fragmentation" has the most negligibly minuscule impact on file read speeds or drive performance, and given the dramatic increase in destructive writes that a file defragmentation would cause on an SSD, it should be avoided under any regular usage.


Hard drives do not have this metadata, the filesystem does.

People use the same filesystems on HDD and SSD drives.

Fragmented files still require more blocks to say where the various parts are.


Hard drives do not have this metadata, the filesystem does.

Yes, this is exactly what I said.

People use the same filesystems on HDD and SSD drives.

Yes, of course, but I'm not talking about filesystems but the reasoning behind why fragmentation matters on Hard Drives and not SSDs.

Fragmented files still require more blocks to say where the various parts are.

I don't have a comparison file to review, but in all measurable and tangible matters, this point is moot as it does not impact SSD performance, only Hard Disk performance is affected by fragmentation.


I just explained it to you. Fragmented files require more reads. Any read is hundreds of microseconds.


And I explained to you, your understanding is incorrect.

An SSD needs so close to the same amount of time to read a linear file compared to a fragmented file that the difference is imperceptible. 0.1ms per seek, less than 1/1000th of what you are claiming.

To directly copy from Crucial's website:

Should I defrag my SSD?

The short answer is this: you don't have to defrag an SSD.

To understand why, we first need to look at the purpose of defragmenting a drive. Defragging ensures that large files are stored in one continuous area of a hard disk drive so that the file can be read in one go. Mechanical drives have a relatively long seek time of approximately 15ms, so every time a file is fragmented you lose 15ms finding the next one. This really adds up when reading lots of different files split into lots of different fragments.

However, this isn't an issue with SSDs because the seek time are about 0.1ms. You won’t really notice the benefit of defragged files — which means there is no performance advantage to defragging an SSD.

SSDs move data that's already on your disk to other places on your disk, often sticking it at a temporary position first. That's what gives defragmenting a disadvantage for SSD users. You’re writing data you already have, which uses up some of the NAND's limited rewrite capability. So, you get no performance advantage whatsoever, but you are using up some of the limited rewrite capability.

https://www.crucial.com/articles/about-ssd/should-you-defrag...


My understanding is not incorrect, please stop assuming that because your understanding is shallow (using consumer-grade information as a reference makes that obvious) that that of others must be as well.

I never claimed that you should defragment your SSD, I just pointed out that fragmentation is still an issue on SSDs, which is a true fact.

Reading a large fragmented file can be 30% slower than if it is not fragmented. Now if you don't think that's significant, you're just silly.


Well, then, instead of being an abrasive speaker, you should point me to sources that back up your claim.

I was able to find a page that talked about write amplification and read speeds decreasing when files are overly fragmented on SSDs, but that was 7 years ago and technologies have improved dramatically since then, not to mention that the effect was found in files split into four hundred thousand pieces, which indicates the slowdown may have been more on the in-drive ASIC not having the throughput needed to deal with that many fragments than with the actual read/write of the disk itself.

https://www.overclock.net/threads/yes-file-system-fragmentat...

Where's your recent (last 4 years) paper or article that indicates that file fragmentation has anything more than a negligible affect on read/write speeds in an ssd?

If you can't put up, then nothing you say matters.


Do you not understand how file systems work?

This is pure logic, no need for any experiment or benchmark.

Fragmented files require reading more blocks. The exact scheme depends on the filesystem used. The 30% figure came from an estimation of the ext4 worst case vs best case of number of reads needed.


A hard drive can give you the next block almost instantly.

But a random block may take many many times that as it repositions the head and waits for the block to come spinning by.

And an SSD returns any block almost at the same speed, so defragmenting only increases the amount of wear on the drive (and it internally remaps anyway so you don’t even get what you’re after - block 5 is a logical block that may be currently mapped to 466 not next to block 6).


You don't just magically know what the next block is.


I’ve found it pretty handy to run a defragmentation in a guest OS before trying to shrink virtual hard drives. Not sure it affects all virtual drives but hyper-v vhdx can compact poorly if the data is quite fragmented and it’s often easier to defrag in the guest if the filesystem isn’t something you have drivers for on the host.


I encourage you to google this.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: