Re: [PATCH 1/2] fs: Do not dispatch FITRIM through separate super_operation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux