On 10-11-18 08:49 PM, Martin K. Petersen wrote:
So assuming we walk the filesystem to reclaim space on ATA SSDs on a
weekly basis (since that's the only sane approach):
What is the performance impact of not coalescing discontiguous
block ranges when cron scrubs your /home at 4am Sunday morning?
In the case of FITRIM, you're right: the performance impact
probably doesn't matter much for a 4am cronjob.
But a lot of people currently (at least) prefer to run it manually,
and they don't want it to take forever.
Though that's still not the primary worry: each TRIM seems to trigger
a flash erase cycle (or cycles) on the most common SSDs on the market,
including anything Indilinx-based and as far as I can tell also for
anything SandForce based. That's probably 70% of the SSDs out there today.
And I'm very concerned about premature wear -- MLC is only for 10000 cycles (avg).
Also, the current one-range-at-a-time interface is just not correct
for the majority of devices out there: they are SATA, not some obscure
enterprise-only one-range-at-a-time thing. We need an implementation
that reflects real-life for uses other than data centres.
If nobody else does it, I'll probably implement it correctly this winter.
But it would really be better for a real filesystem/DM person to do it.
Thanks for hanging in there this far, though!
Cheers
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
