TRIM support for SSDs in Lion

on MS/Apple drivers:

Via the Identify Device data word 105, SandForce tells the AHCI driver that it doesn’t accept more than a group of 64 entries at a time, a parameter that is respected by the Intel RST driver.

However the Microsoft TRIM driver doesn’t respect this and continues to send 4 to 8 sectors at a time, which doesn’t comply with the latest ATA standard according to SandForce and goes beyond the specifications of the SSD exposed to the driver, which means that these commands aren’t accounted for by the SSD. This is why on SandForce SSDs TRIM only works with the RST drivers!

http://www.behardware.com/news/10962/sandforce-trim-listen-up.html

I don't know if problem still exists, but ^^^THIS^^^ is properly reported huge problem with drivers, not some "my mac can't wake!" shouts, isn't it? MY mac with SSD perfectly wakes after anything - so what?

Yes I know that LBA addresses DO not Translate to Flash,Die addresses, if you bothered reading what I posted before, I say that the SSD controller remaps LBA addresses a virtual space to an SSD address, and there is no corrolation b/w the two other than what the SSD contoller makes it out to be.

Yes I know TRIM sends LBA block addresses, and there can be multiple LBA blocks inside a FLASH Block (Pages are 4KB and BLOCKS Are 512KB),

If the SSD is full as seen byy the Controller, the Garbage Collector can only collect the upto the over-provisioned space on the drive.

No amount of "Unicorm powered Sparse files" will help you with stale blocks, the GC will only mark them free once they are over written to, but then you pay a performance penalty, which is what TRIM is trying to avoid, I guess I should of mentioned this earlier but You cannot just over-write data on FLASH-NAND, you have to send an ERASE command which puts the FLASH in a state to write data to.

So assuming your SSD controller sees the drive Full (NOT THE FILE SYSTEM) It would have to do an operation similar to this

Data -> Read Old Block -> Modify Old block with new Data (in RAM) -> Write to (overprovisioned space) -> ERASE old Block-> GC Claims the OLD Block -> Update Structures

There are several operations there that are not needed, first reading the stale data, then the erase command. If the SSD had been 'trimmed'

Data -> Write -> Update Structures

THIS IS WHY YOUR SSD IS SO FAST when you start.

Degradation in performance is right there, Benchmarking is a science, you only modify one variable otherwise you invalidate the entire benchmark, and in this case they tested TRIM and NO TRIM. No amount of "overhead of maintaining stream (s) contiguous on-the-fly" or vague statments with no proof or evidence invalidates it. Its quite simple with TRIM: 202 , NO TRIM: 160 Then again this is the reason why I CHOSE a SF based SSD because of that degradation difference, and other SSD's would probably have a greated amount of performance loss.

I havent found anything related to your statement other than that link which only states that the TRIM command is affected for file sizes bigger than 4GB. The article also mentions that the manufacturer OCZ was affected, but then again given this : http://www.theregister.co.uk/2011/06/22/ocz_vertex_flash_bsod/

Given that their firmware seems to about the only difference b/w other SandForce users, I am more likely to bet that OCZ's obsession with speed got them in trouble.

Also given that was the ONLY site I found which had reported the issue, I have doubt about their research, I only found this forum post discussing it : http://forum.corsair.com/v3/showthread.php?p=482979

Given how common the MS AHCI driver is, I am some what surprised it there wasnt a reference about this issue on MS's KB database, but what I did find it was an interesting interaction b/w AMD, MS and you guessed it SandForce.

I cannot confirm your statement regarding the SATA - TRIM spec, because I dont have a Copy of the Spec to read just yet, when I do I'll double check your statement, otherwise please back it up with evidence.

You can just use apple search for: OSX SSD Panic, or even at forums.whirlpool.net.au, you can even try OSX SSD Hybernation, but if you wanna live in a dream that everything just works go ahead.

Oh really, is this why the RST drivers are a problem with OCZ SandForce for updates, as stated in this toolbox http://www.ocztechnology.com/ssd_tools/OCZ_Vertex_2,_Vertex_LE,_Agility_2/

This OCZ Toolbox does not work with Intel RST 10 series drivers

FAIL

a) to close the thing - I have no special interest and knowlege on Win SSD drivers - that was just example of difference between "problems" and properly identifyed problems with drivers. Nothing more. And I btw personally dont like SF controllers and dont use them. No advertising from me here. They dont fit my usage case.

b) Don't go upset, look. You have no need in erasing block immediately. You need just some cleaned block for next ONE write, no more, for full speed of drive. Just ONE clean block, when it is needed. And ONLY AFTER writing to that one block you'll need next one. And after next write - next one. I'm oversimplifying, of coarse, but this is the idea.

when you have virtual image fitting full drive size - you have 2 things.

1) you still have over-provisioning space (never seen less that 7% of drive - ie some gigs anyway) and that space is clean and ready for write - as it was "out" of image and cleaned

2) every write to drive will mark something in image as "waiting for clean" as in this situation ALL lba space is in image

So as a result - until you write something less than overprovisioning spase - thing will work

You wrote sheme (slow):

Data -> Read Old Block -> Modify Old block with new Data (in RAM) -> Write to (overprovisioned space) -> ERASE old Block-> GC Claims the OLD Block -> Update Structures

and another one: (fast)

Data -> Write -> Update Structures

But man, you should define for yourself - do you work with compressed stream or not. first one is definitely for compressed data stream, second one - for uncompressed. You can not just "write" in the middle of compressed stream, you have to attach in some way your data into it, so you will have read -> modify -> write instead of simple write anyway - only other way - if you will use single -block internal compression, which is absolutely idiotic approach

so we have the same

Data -> Read Old Block -> Modify Old block with new Data (in RAM) -> Write to (overprovisioned space)

for write on trimmed SSD - of coarce if it uses internal compression.

You see? The absolutely same speed of write, until there are spare space

Do not think about "how I can clean just erased blocks?", think about "where I can get clean block for write?", it's HUGE difference

It's absolutely irrelevant, when exactly freed blocks are cleaned - important is that you have enough spase for next ONE write.

Yes, degradation exists - but it's almost negligible for SF-2xxx controllers I'm talking about. And mostly it degrades in what situations? Not in real life but in tests, which stress drives badly - thus outperforming drive's GC.

BTW, its easily doable - just long enough you should support writes to drive with more than 1/2 of write bandwidth - it's like basin with two pipes math basically - cos GC have it's own speed. But its not reallife usage case for 99,95% of owners - to support write stream 300 MB/s during 1000 seconds for 100 GB of free space on drive - that it can be ignored, I think

BTW, I'm really interested in real TRIM implementation for compressed stream of data. Can you show me just this? algo for translation LBA addresses into NAND addresses - where NAND contains compressed LBA space, with floating compression ratio - and than erasing NAND blocks? Fast one?

is there any way to PM somebody? if no - I'd better like to communicate on this over dmdimon at gmail dot com as we're really far from top[ic and I think far from field of interest for almost anyone here.

Message was edited by: dm_dimon

edit

actually there are a way to implement simple write on compressed stream - but it goes with overhead (on cleaning) far worse than decompressing two additional blocks

actually it's chinese for me, but i found a workaround for trim on non-apple ssd's

http://www.mactrast.com/2011/07/how-to-enable-trim-support-for-all-ssds-in-os-x- lion/

TRIM Enabler for OS X -

Your SSD already has built-in garbage collection. TRIM and garbage collection are similar, but they are not the same thing. Unfortunately, for some reason, the Apple driver for TRIM seems to conflict with drives that have garbage collection built-in to the controller, so you won't want to use it. It'll actually decrease your drive's performance.

http://lifehacker.com/5803331/how-to-enable-trim-on-your-macs-solid+state-drive

TRIM Enabler - cindori

http://www.groths.org/?page_id=322

does an OCZ Vertex2E (120GB) support Garbage Collection?

trim enabler does exactly all this chinese thingy by pressing one simple button 😉

The hatter, I beg you - trim does not conflict, somebody at lifehacker just got mistaken, do you have any evidence other than that?

I know no one simple example of conflict - and I have 3 SSD with GC personally with trim enabled and run tens of gygabytes over them everyday, and I'm involved in big enough community - tens of thousands users at least, and i'm monitoring over net on this, and i really, really do know how it works.

There are no known problems in this functionality of Apple driver. There ARE slowdowns - I wrote above on this - but not conflicts.

And - if you track down trim enabler thing - you'll go to some first ever post on this, dated march 25, 2011:

"Hello Mike. I have good news for those people still waiting for support of TRIM command for third-party Solid State Drives (in OS X). Now we have a support!"

http://www.xlr8yourmac.com/archives/mar11/032511.html#OSXtrimSupport

So, that actual author of trim enabling hack - not cindori, but Victor D. , take a look at end of story. cindori - just packager. Respect 2 him for nice utility, but not forget to respect author.

dmdimon wrote:

The hatter, I beg you - trim does not conflict, somebody at lifehacker just got mistaken, do you have any evidence other than that?

::WAVES HAND:: I do! I do! The TRIM Enabler DOES NOT (work with my OCZ Vertex 3 with the SandForce 22xx controller in it) on my new 2011 MBP. I get the 15-30 second beach balls. I disable TRIM and everything is fine.

Also FWIW, I was told by OCZ Support that TRIM was not needed with the Vertex 3.

no, you don't have conflicts, you have slowdowns

see in my post above - "There ARE slowdowns - I wrote above on this - but not conflicts."

Did you have data losses? Did you have FS corruptions? Did it brick your SSD? Did you have any issues other than slowdowns?

I'm just truing to say that it is safe. It is just not needed for (almost) all with SF2xxx - and it will slow such drives - buut not due to trim implementation in Apple drivers, but due to controller specific. In next turn, I don't want to say that SF2xxx are somehow bad - they are good actually - but they are just other, and trim is emulated on them, thus slow. And this is almost irrelevant - as they in 99.95% usage cases dont need trim.