I don't understand, if sequential reads and writes are so much better than random on SSD, why is defrag pointless? (I know SSD have limited number of writes).
If physical sectors don't match logical, then what does 'sequential' in speed tests mean?

in short: defrag is used to collect the different parts of the same file into the same or near location (track) - if possible. That will lower the head movement. In ssd there is no moving head and access (speed to) the files is not influenced by their storage locations.

1 members found this post helpful.

why are then sequential speeds higher in benchmarks?

can you show an example?

take any benchmark, for eg: http://www.anandtech.com/bench/product/966

128KB Sequential Read (4K Aligned) is 429,8 Mb/s
4KB Random Read (4K Aligned) is 91,7 Mb/s

I think you misunderstand the testing methodology and terms. Those result factors have little to do with fragmentation.
(As in, some but not much.)

well what am I missing? if we have defragmented file, it would be read sequentially; badly fragmented one would be read 'randomly', is it not so?

I googled "ssd random vs sequential read" and found this interesting series of articles on SSD:

from codeCapsule.com (blog): Coding for SSDs

There is a lot there, but scroll down to the Table of Contents and click on (or click here) Part 5: Access Patterns and System Optimizations and look it over.

The short answer, I guess, is that sequential vs. random throughput depends on the internal parallelism (number of chips and channels), internal block and page sizes, and other details of the SSD. I haven't got it all figured out, but if you read those articles, I think you'll know more than most of us and you might find out whether defragging helps and why.

1 members found this post helpful.

I've found that with newer kernels and large disk sizes and modern filesystems, defrag is a thing of the past. Try using 'filefrag' to check for fragmented files. All files should have 1 extent, this means fully defragmented.

1 members found this post helpful.

A mechanical hard drive places stuff in different areas. The reason you defrag is to get data as close to each other.

A SSD has no such need to be close. It takes the same time to access a block on one part of memory as it does the other.

Also they do house keeping internally so no real need unless you are trying to salvage a few bits here and there.

Linux filesystems don't fragment files like Windows does (or did, I haven't kept up in the past few years with Windows). Linux doesn't even have a defragmentation tool, and doesn't need one.

Actually XFS has a sparse defrag tool. Note that originally defrag was not sparse. As jefro suggests, for FAT and NTFS defrag means moving data closer together. Well, that's not what is done or should be done with modern filesystems. What you want is sparse defrag. Keep files apart, but keep them contiguous. Again, it's not needed with newer kernels and large drives.

1 members found this post helpful.

It is not really true that linux doesn't need to be de-fragmented. It does or can get fragmented and in server rooms one may need to check that many times a year. It would depend on a number of factors but I'll agree that most home users never would notice an issue.

2 members found this post helpful.

This is with newer kernels ? 3.10.x and up ? I've noticed a big change in fragmentation level with newer kernels vs older ones, so I have to ask. I know when I was using older kernels I too had to defrag and there are a number of script available to do so, but I don't use them anymore, because I don't have to.

1 members found this post helpful.

@Beryllos
thanks for the link. I think I (somewhat) understand it now.
To achieve sequential read speeds, one probably has to write sequentialy, so that SSD knows how to efficiently place bits in parallel.
defrag programs probably write block-by-block, instead of file-by-file, so they wouldn't speed up disk.