Comment by charcircuit
1 day ago
Sequential reads are faster for SSDs. As long as defragmentation is reducing the chance of doing a random read, it is beneficial.
1 day ago
Sequential reads are faster for SSDs. As long as defragmentation is reducing the chance of doing a random read, it is beneficial.
OH! TIL! Apparently
Still, given SSDs have a lifespan and given few of my files are that large, I think I'm personally okay without defragmenting. Those numbers are impressive but, most of 10s of thousands of files are source code text files. Asking online what the real-world loss is from not defragmenting
> You are giving up virtually 0% to 3% of real-world performance. In daily development, media editing, and standard system use, defragmenting your SSD will yield no human-noticeable speedup.
Is it possible to determine which sectors are physically sequential given remapping for wear-leveling?
Otherwise the claimed defragmentation here is not actually resulting in sequential data.
You cannot directly inspect the degree of fragmentation, because it has less to do with being contiguous in the Logical Block Address (LBA) space and more to do with having been written at the same time. To properly defragment a file on a SSD, you pretty much need to sequentially re-write the whole file in one go, to a newly-allocated part of the drive's LBA space.
> to a newly-allocated part of the drive's LBA space
Which is rather a case for home use, not practical for highly parallel access industrial use cases. That's why the issue became a research topic. For the first time I saw a proof that the "fact" SSDs do not need defragmentation is actually a myth. Well, you still want to avoid explicit defragmentation (waste of time and SSD lifetime) by filesystem driver submitting additional hints (using new NVMe extensions) to the SSD controller about what blocks belong to the same file, so that SSD can place them for an optimal sequential access with properly interleaving (not necessary strictly physically consecutively whatever this means on SSD).
https://www.usenix.org/conference/fast24/presentation/jun
>Otherwise the claimed defragmentation here is not actually resulting in sequential data.
I haven't measured it but the SSD firmware should be able to look up where the next block is speculatively in order to be able to immediately start sending it if the host tries and read the next block (as opposed to a random one).
Prefetching applies to SSDs too, and that's generally sequential in some sense.
[flagged]
SSDs often interface with their storage in different (larger) granularities than the OS meaning that even though the data is effectively more random at large scale due to wear leveling there are still benefits to keeping blocks that are sequential in your file sequential in the filesystem also. As well as a potential read boost, the larger blocks introduce a read-before-write issue that can allow multiple close updates.
The difference is very small when compared to the differences between solid state and spinning rust based solutions, but definitely measurable, particularly on drives with DRAM cache, and in some cases human-noticable.
Actually read the article and you'll see the author specifically talks about this begin part of why this side project started (though I suspect nostalgia is the true driving force as there are more efficient ways of addressing that matter!).
I'm pretty sure you don't understand how threads in discussion works.
But, hey. Atleast you can write ~1000 chars with absolutelly no substance fo prove that you know nothing about the topic. What a life to live.
1 reply →