MS (ms@lostcircuits.com) on 1/24/11 wrote:
---------------------------
>anon (anon@anon.com) on 1/24/11 wrote:
>---------------------------
>>David Kanter (dkanter@realworldtech.com) on 1/24/11 wrote:
>>---------------------------
>>>anon (anon@anon.com) on 1/22/11 wrote:
>>>---------------------------
>>>>Rob Thorpe (rthorpe@robertthorpeconsulting.com) on 1/22/11 wrote:
>>>>---------------------------
>>>>>Linus Torvalds (torvalds@linux-foundation.org) on 1/20/11 wrote:
>>>>>---------------------------
>>>>>>Megol (golem960@gmail.com) on 1/20/11 wrote:
>>>>>>>
>>>>>>>Linus "ass***e" Torvalds not understanding something and insulting everyone that
>>>>>>>have a clue. How come I'm not surprised?
>>>>>>
>>>>>>Why do you think I'm here? If I wanted to have an intelligent
>>>>>>discussion with people I care about, I'd be writing emails
>>>>>>to kernel people. "Arguing vigorously" is my hobby.
>>>>>
>>>>>To put things differently, for the purposes of RWT forums you're a troll.
>>>>>
>>>>>What I can't understand is why Dean and David have let your behaviour in this thread
>>>>>go and not thrown it into the unmoderated forum.
>>>>>
>>>>>FWIW I don't know or care much about TRIM. But, I'm reminded of a line from "The Big Lebowski"...
>>>>>
>>>>>"You're not wrong Walter. You're just an asshole."
>>>>
>>>>Pretty sure everybody else was wrong and an asshole. Linus had actual numbers and
>>>>real reasons. Everyone continued to bait him and handwave and assert how they were
>>>>right and he was wrong with nothing to actaully back it up.
>>>
>>>As a number of people pointed out, the numbers were intriguing and surprising...but
>>>it's hard to judge them given the lack of test conditions.
>>>
>>>>Let's be clear here. People were not saying "Oh well I would have thought trim
>>>>should be fast because X, so given the actual numbers and experiences you have provided, I wonder if Y".
>>>>
>>>>People were saying "No I'm right and you're wrong, trim is fast and obviously always
>>>>right to always do it. I have no numbers and nothing but vague handwaving about
>>>>what I believe an FTL should do, but in any case you are definitely wrong.".
>>>
>>>Actually, it seems to me that the overall response was: "Yes, it appears that some
>>>drives with TRIM have a really really crappy implementation that causes problems,
>>>that doesn't necessarily mean that the idea sucks though."
>>
>>Nobody says the idea sucks. Even the implementation it is agreed that it is a no-brainer
>>to use in offline mode, regardless of the drive implementation.
>>
>>But the assertion that it is trivial to implement in FTL is absolutely wrong. To
>>actually go through the thought exercise of why, then you need to build up the entire
>>log structured block device system to be used.
>>
>>It is hardly likely to be a simple forward map in fast RAM which requires only
>>a few instructions to switch, and is all magically backed by supercaps etc etc.
>>
>>If you try to make the argument that it is simple, you can't just handwave away
>>all these details and assert that you are right and therefore everyone else is wrong.
>>
>>
>>>TRIM is a pretty complex subject - it doesn't work real well in RAID and many enterprise
>>>systems will probably disable it, in favor of techniques that scale over multiple SSDs.
>>>
>>>As was also pointed out, it many respects, a DRAM or SRAM write combining buffer
>>>is a vastly better solution - however many vendors avoid that for cost reasons.
>>>Some for data safety reasons. It seems to me that this is an area likely to see improvement...but hard to say.
>>
>>No this wasn't pointed out, it was handwaved. It's not that simple, even if you
>>have caps to write out several megs of data (as I pointed out, the full mapping
>could be well over a gigabyte in size).
>>
>>>The point that using TRIM as a crutch for a cheap/crappy SSD seems pretty valid.
>>>I think a more interesting point is whether a good TRIM implementation can improve
>>>performance/longevity for a properly designed and suitably robust SSD.
>>>
>>>Another related question is whether changes in the FS would help (or not).
>>
>>The point is that for a _lot_ of usages, trim is pure overhead regardless of how
>>well it is implemented, because the filesystem is likely to use logical blocks again.
>>So the question of how well it can be implemented does not even come to figure.
>>
>>Given that, it hardly seems like something that an FTL should optimize for (at
>>least, if it comes at the expense of normal re-write reallocation, or requirement of a lot of battery backed dram).
>>
>I don't mean to be the party pooper but let's get some things just re-aligned here:
>
>1) TRIM addresses the fundamental problem of NAND flash that you cannot overwrite
>"used" blocks. Used is the currently official JEDEC terminology to distinguish from
>"occupied" blocks and used means that the blocks have been programmed but don't
>have any valid data (since they have been moved elsewhere). TRIM simply causes a
>pre-emptive erase of these blocks to reconstitute 1 (or 11) values for all cells
>so that they can be written to without first erasing the block completely.

Trim addresses this problem, but rewrite also has to address the same problem, and is much more common to boot. The trend in most storage is to slowly increase the amount of data stored there.

The window that realtime trim can fit in, between the use of periodic offline/not realtime trim and the case of blocks being rewritten, is _not_ very large.

Hardly large enough to be any sort of "game changer" for most workloads even with a really fast trim implementation.

>2) TRIM does often not work in RAID because of several reasons, the primary one
>being that most of the RAID controllers are still not completely understanding the
>difference between HDD and SSD and therefore do not pass the TRIM command to the
>devices. Depending on the configuration of the RAID (true RAID or just striping
>/ mirroring), there are additional issues that I won't go into in public.
>
>3) TRIM only works if there are idle cycles, if the drives are subjected to 100%
>load all the time, then there is simply no time to execute TRIM without inserting
>idle periods. This is the scenario that Linus referred to, however, outside any
>extreme case in the enterprise environment, it will happen in a blue moon.

No this is not the scenario, and this does not prevent trim working. If trim was a win then it would be worth the small cost to insert trim to make the drive more efficient in subsequent operation.

What Linus is referring to is that *blocks are overwritten after they are freed*. With alarming regularity, actually. Making realtime trim almost completely useless work, whether the disk is 100% utilized or 10% utilized.

>
>4) Drives that use de-duplication of data on the controller level like e.g. Sandforce
>don't necessarily need TRIM because something similar with approximately the same
>net-effect is already standard operation of the drive.

No. Filesystems don't typically zero blocks when they deallocate them.

>
>5) At least in theory, the number of P/E cycles is the same whether TRIM is used
>or not. What is different is the time at which the erase is executed, that is, whenever
>there is some time a which it appears opportune because no other workload is outstanding
>or whether it is immediately before a re-write. In practice, the change in programming
>frequency (cluster vs. distributed) will have some effect on the life of the NAND cell.

Active data will certainly incur a higher P/E cost in the course of a drive lifetime to manage. I don't know what you're trying to say.

>
>6) Any drive experiencing idle cycles during which it is able to perform TRIM will
>restore steady state by reducing the number of "used" blocks, which, over time will
>dramatically improve write performance to somewhere between 60 and 80% of a new
>drive whereas without TRIM, that same write performance will slowly degrade until
>all blocks are used and then level out at a much lower performance level.

So that obviously depends totally on the FTL and exactly how many blocks were freed, how they get reused, how they get trimmed etc.