cmthomson wrote:each page (typically 128KB) is erased.
You misread the review. They say about 128 pages 4K each creating a single erase block. And 0.5 MB block in X25-M is very small, 2-4 MB is more like average.
cmthomson wrote:Defragmenting an SSD is a mixed bag. It reduces the number of small random writes by consolidating fragmented files onto fewer pages (reducing future erases), but it also does lots of writes, which means lots of current erases. I'd suggest defragmenting about once a week or so.
Not really. File fragmentation doesn't cause _any_ additional writes because you write only on the free space, don't you? So defragmenting free space could be beneficial and additionally defragmenting files could be used to prevent future fragmentation, exactly opposite to what hard drives need and what defragmenters do, except for a special version for Diskeeper.
But there's one more thing to think about and I don't know how it is.
Wear leveling uses remapping and what it shows to external devices has little to nothing to physical data layout. What looks as a continuous block for OS is most likely scattered all over the SSD.
Now there's a question: Do they remap pages or erase blocks? If blocks, then there's some connection between physical and logical layout and considering that blocks can be big (like 8 MB), this might make defragmentation help somehow. But to really work well, defragmenter should be aware of erase block size and don't do optimizations over the whole drive - they are pointless, but optimize each block independently.
But I think that SSDs don't remap blocks, but rather pages, it would allow way more efficient wear leveling. If you make a large, continuous write, SSD most likely will write it more or less continuously to make less total writes. So heuristically, some blocks that appear continuous, are continuous, which may make SSD aware defragmenters have some positive effect. And there's one more question: How long does the rule last? After 3 years and 2 OS reinstallations, there will be little logical blocks that aren't scattered physically unless firmware tries to optimize it.
ADDED: I checked one thing that could prevent remapping at the page level: Bigger map needed.
For 64 GB disk (raw capacity including inaccessible reserve) that's ~48 MB or 0.073%.
Grows with capacity, for 1 TB you need 0.085%. Still no problem, I guess.
