A Sequential write is of course much simpler: Just write it directly to disk!

Wear-Levelling is actually making these things somewhat more complicated, especially since manufacturers don’t disclose their individual algorithms.

Then I did that online conversion with e2fstune:
boot: 43s
VCD: 31s
I was impressed by the write speed for large files but the boot time was unsatisfying. I tried e4defrag, but it did NOT add the ‘e’ attribute as reported by lsattr to all my files. So I made a backup of my data and formated the root partition.

With a fresh ext4 file system and all data copied back with rsync I got this result:
boot: 34s (It was 26% slower before)
VCD: 30s

Now that’s how I like it! Wether there WAS considerable fragmentation on my ext3 fs or some feature of ext4 wasn’t active after the online conversion, I don’t know and don’t want to join the flame war. But if someone asked me I would advise them to reformat.

The reason there is any difference at all between requests is that accessing a large file is considerably less IO requests than accessing a lot of small ones, and its those requests for read/write operations that seem to clog up SSDs.

Fact is, data is not allocated how you think on an SSD anyway. They are designed to fragment the data intentionally due to the wear levelling process. The REAL killer for SSDs is low disk space, as the wear levelling demands that every write operation can be allocated to a different part of the drive (the least used). So if you have very little free space, it struggles to operate correctly. But that is also why defragmenting an SSD is pointless, you would just be jumbling the data at random around the drive wasting write cycles of the flash chips.

For example, take the Intel X25-E. Sequential writes are almost 200MB/s. Random writes are more like 35. For 128GB Indilinx MLC drives, the sequential write speed is around 130MB/s, but the random write speed is around 10MB/s.

If free space on an SSD is heavily fragmented, then writing new files to the SSD will be at close to the random write speed. If an SSD is not fragmented, then writing new files to the SSD will be at close to the sequential write speed.

Even read speeds vary somewhat. Sequential read speeds range from around 120 to 280MB/s. Random read speeds range from around 25 to 60MB/s. So even filled space benefits from defragmentation.

That said, the algorithms used to defragment data stored on SSDs should be very different from those used to defragment data stored on rotating media.

/quote

for SSD fragmentation is not an issue since the slowdown caused by fragmentation is a result of the seeks (hard disk head movement). An SSD does not do any seeks (no head ).

/end-quote

YES! finally someone who understands how a disk drive works! And why fragmentation is indeed an issue in ANY operating system!

Just as an extra note: it is not only the seek time for the heads, but also the rotational latency to consider as well… (for those who do not understand: the time it takes for a requested sector to appear under the read-heads, once the heads are on the right track)

This is not so much an issue if the read is sequential (i.e. a single contiguous stream) but as soon as jumps to various tracks (=fragmentation) are required this definitely becomes an additional factor!

The total seek time (access time) for a requested sector is:
software overhead to issue commands (very minute)
+ track seek time (considerable) (=accellerate + travel + decellerate + stabilize time)
+ rotational latency (=wait for sector to pass-by) (considerable, depends on drive rotation speed)
+ cache handling time on the drive (very small)
+ transport data time (very small).

(hence why SSD does not have the problem)

I can tell you from 30 years experience: optimizing definitely matters. Especially on high-load server systems. If you just read a text-file once in a while, then fragmentation wont matter indeed…

And I am not affraid to use the word “defrag”… Anyone who starts a flame war over this simply does not understand (or does not WANT to, even worse) how a hard disk works….

gr

for SSD fragmentation is not an issue since the slowdown caused by fragmentation is a result of the seeks (hard disk head movement). An SSD does not do any seeks (no head ).