On Feb 8, 2014, at 3:04 PM, Michael Cronenworth <[email protected]> wrote:
> On 02/07/2014 06:54 PM, Chris Murphy wrote: >> And here is a recent thread, just under one year old…. >> >> https://lkml.org/lkml/2013/2/23/107 >> >> Anyway, the fs developers have been speaking about it quite a bit and for a >> long time. > > I guess I could have Google'd for this, but after reading over a few of these > links they don't produce any quantitative evidence that TRIM (in its current > state) causes a significant problem. So what you really wanted was quantitative evidence, rather than reading what fs developers had to say about using trim. In that very thread, the O.P.s problem was solved by removing the discard mount option. I don't understand how that's not qualitative evidence, or how the described problem wasn't significant. There are all sorts of threads where users are having brief system hangs, to outright sluggishness, and they go away when trim is disabled. And even aside from what you might consider minor performance hiccups, how about it being totally disqualifying for use in raid of any sort if trimmed sectors return non-deterministic results when subsequently read? > I see theoretical discussions that TRIM, being non-queued, can be > detrimental. However, real-life performance tests show TRIM use to be > insignificant. It clearly depends a lot on the SSD used and workload involved. That sata-io have published SATA Rev.3.1 with a queued trim command expressly to address the problems that occur when mixing queued and non-queued commands in typical usage seems fairly significant to me. The storage manufacturers agree with each other almost as a last resort, and rarely so quickly. > > Windows 7 and higher uses TRIM in a "discard"-like manner and it is > automatically enabled. I do not hear of Windows users complaining about poor > performance or blog posts recommending it be disabled (in fact Google will > show the opposite). I supposed you've Googled this with the same thoroughness as before? As it turns out there's quite a trove of results for people having short freezes in Windows attributed to SSDs. Once they learn how to disable trim for the drive, their problems go away. It's also misleading to say that Windows always enables trim, because at least if the drive isn't also supporting drat and dzat it won't enable it. And not all drives do support some form of deterministic read after trim. I'd characterize the problem as a minority case, but it seems in the vicinity of a significant minority, if you have certain cheap/crap SSDs on the market and a workload that triggers the problem. But it's not like it's rare, and it's not like it's a figment of people's imagination. Like I mentioned before, Apple doesn't enable it on any 3rd party drives by default, and it's not because they can't. It's likely because of the way they're constantly creating and deleting small files (mostly application preferences and system configuration files) in order to get something like what COW file system would get them for free, they create a new file, and delete the old on rather than overwriting it. When I had trim enabled in OS X with my none crappy or cheap Samsung 830, I noticed an occasional 3-5 second freeze where the system wasn't responsible. After disabling trim the problem went away. With or without the discard option with Btrfs on the same system, I've thus far experienced no difference in behavior, but then Btrfs is COW and likely has substantially better delayed allocation and batch trimming than what Apple is doing. But yes that's all rather anecdotal than either qualitative or quantitative. Chris Murphy -- users mailing list [email protected] To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
