"Well, finally we can make some jokes about
nMP's having a washing board inside" said a cheese grater to the other cheese grater! 
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
OWC posted preorder for 2TB SSD for nMP6,1 today
- Thread starter bxs
- Start date
- Sort by reaction score
"Well, finally we can make some jokes about
nMP's having a washing board inside" said a cheese grater to the other cheese grater! 
When data is written to an SSD, if the NAND block has any existing data in it already, the data needs to be read, the block erased, and then the whole block (with new data and old) rewritten. This read-erase cycle incurs a performance penalty and thus it's ideal to write to empty blocks.
GC helps by collecting pages of data into complete blocks and doing it's best to free up blocks so that this read-erase penalty can be avoided. However, due to the fact that file systems are abstracted from the media, they do not communicate which files are deleted, GC will continue moving deleted data around. And since it's juggling deleted data along with relevant data, it's got less space to work with and therefore less truly free blocks that can be used without the read-erase penalty.
TRIM aids CG by telling it which data has been deleted so GC doesn't need to keep moving it around. It's a pretty simple solution really... much simpler than the alternative of writing a new file system.
GC cannot possibly duplicate TRIM. All it can do is it's best to maximize the number of free blocks of NAND. TRIM makes this much easier. GC without TRIM is moving a lot of data around that may no longer be needed. People use to say that because SandForce compressed the data, there was actually more free space to work with than it appeared so it's GC could do a better job. The fact is, even Sandforce GC will eventually get burdened and run out of free blocks and in the absence of TRIM will degrade.
This is about the funniest thing that I've ever read on MacRumours !
Especially since about the only bit of fact involved is that proactive *garbage collection* will run when the disks are idle (that is, often when the screensaver is running).
Quoted for truth. Without TRIM (or some magical alternative that no one has proposed) GC can't tell if much of the data is in use or not. The GC will be moving data that the filesystem has deleted - which means that it is writing data that doesn't need to be written.
Isn't a big issue for prolonging the life of SSDs trying to reduce the number of writes? TRIM reduces the number of writes that the GC has to perform. Without TRIM (or the magical alternative) the GC has to write deleted data.
TRIM also lets proactive GC create large pools of pre-erased empty blocks - so that big writes complete at full speed, rather than slowing to a crawl when there are no pre-erased blocks and writes have to wait for on-demand GC to move data around and erase blocks. With TRIM, all of the free space on the drive is effectively part of the "over-provisioned pool".
What's not to like about that?
Last edited:
I was being sarcastic.
And clearly this site is lacking in humor if that, or your hamfisted attempt of mockery, qualifies as funniest.Point is, TRIM is a PoS solution. It requires a trigger from the OS. Garbage collection is self triggered. BTW, which is not to say I like OWC or whatever, just I'm more ideologically aligned with the idea of drives that take care of this leveling without trim, especially since Apple is making TRIM a s**tshow with 3rd party drives.
It wouldn't take a lot of effort for the drive makers to invest in understanding directory structures of NTFS, HFS, FAT32, Linux and baking that into GC. No doubt TRIM helps, but its still a s**tshow of an implementation. And apple sucks for not supporting it as well, despite it being craptacular. And in practice, plain GC works great. 40GB free on a 960GB SSD, never bothered to put TRIM on, just with GC. Been using the drive HEAVILY for over a year (might be 2), writes are super fast. I hear what you're saying where it could degrade, but the reality is GC is good enough and doesn't need the OS overhead of TRIM. At least in my experience. YMMV.
Embedding knowledge of filesystems into the SSD firmware is an incredibly bad idea.
Not only do you have synchronization issues, you have issues with filesystem evolution (and "Linux" isn't a filesystem, it's ext2,ext3,ext4,zfs,xfs,btrfs,...). See http://en.wikipedia.org/wiki/Comparison_of_file_systems .
On top of that, if you have software or hardware RAID the individual drives don't have the full filesystem visible - so the drive is blind.
I don't see any synch issues, but then again, I'm not a file system coder. the RAID issue is real, agreed. The evolution issue, I don't think is, as the deleted space isn't going to change in any real way, much as the directory structure. Take a look at disk warrior. Ancient versions still work even with modern version of the file system to do significantly more complex work. Yes they keep improving it, but the old stuff still works.
Lastly, the main point is GC works well in practice. Very low free space drives, after years of work, are well leveled, so while the theoretical problem exists that somehow deleted blocks can be overlooked without trim, in practice, it works fine and the drive writes are still fast.
Some questions and comments.
- Your 960GB SSD really contains 1100GB of NAND, overprovisioning by 140GB.
- Is your "40GB" free what the filesystem in a 960GB partition reports, or did you do additional overprovisioning and create a 920GB partition to increase the overprovisioning to 180GB?
- If the former, you might not have any free space. Without TRIM, if any block is ever written, it's in use forever* regardless of what the OS reports for unused space.
The beauty of TRIM is that any free space in the filesystem is effectively overprovisioned space. If you fill the disk, the overprovisioned percent drops. As you free up space, the overprovisioned space increases.
* "forever" means until a secure erase resets the drive to unused.
Consider the sequence:
- user deletes File1
- user creates File2
In a naïve view of a filesystem, you might expect that this would result in:
- user deletes File1
- filesystem updates on-disk metadata to reflect deleted file
- user creates File2
- filesystem creates on-disk metadata to reflect new file, and happens to reuse the disk blocks used by File1
- filesystem writes user data to File2
You proposal for embedding filesystem semantics in the SSD firmware would change this to:
- user deletes File1
- filesystem updates on-disk metadata to reflect deleted file
- SSD firmware marks disk blocks used by File1 as "free" (erases them)
- user creates File2
- filesystem creates on-disk metadata to reflect new file, and happens to reuse the disk blocks used by File1
- filesystem writes user data to File2
In the most common modern real-world filesystem, the actual sequence with your "enhancement" could easily be:
- user deletes File1
- filesystem updates on-disk metadata to reflect deleted File1
- user creates File2, and happens to reuse the disk blocks used by File1
- filesystem writes user data to File2
- SSD firmware marks disk blocks used by File1 as "free" (erases them)
- filesystem creates on-disk metadata to reflect new File2 (but unfortunately, the SSD has already zeroed the data in File2)
Sound crazy - but this is exactly how NTFS and modern journaled filesystems are designed to work!
If you follow that link and it seems complicated - then you know exactly why I said that making the drive firmware aware of the filesystem on-disk structures is a very bad idea.
Especially since there's a simple and elegant solution called TRIM (or "discard") that lets the filesystem inform the disk (at step 2 in the last sequence) that blocks aren't referenced.
Last edited:
I don't follow that, frankly, and I don't know why GC has to read an older state. I'll defer to you, but I'm just not buying that TRIM is a good solution. Bottom line is the drive should be able to know whats empty and pave it without help from the OS. But what do I know.
Yes, my drive is 960GB, and 40gb is free from that. So 920gb used. 7% is fine, and the result is the drive works great, and doesn't rely on the OS or the wackjob unpredictable support of Apple.
On the long run TRIM is indispensable.
The comparison of TRIM garbage collection (GC) is incorrect, and the statement "TRIM is a command implemented in the OS and erases cells that are no longer in use." is incorrect.
TRIM does not delete anything, but only marks as deleted. Deleting still does the Garbage collection of the SSD. The GC works closely together with the wear leveling and tries to create as many free cells, and spreads the use of the individual cells on the entire plate.
However, only those cells from which the SSD controller knows that they are empty or no longer in use, will be included in this GC mechanism.
If the system (or the user) deletes a file without TRIM, no more required cells are going on the journey across all blocks. Quite unnecessarily. This means that at each optimization of accesses to the SSD, tons of invalid data is moved. The GC can not be so sophisticated, it inevitably fails because the GC has to rely on for information, which blocks contain invalid data.
Without TRIM the SSD must wait until the operating system requires a specific block for writing, which already contains data. Only then the SSD knows that the data in this block are not needed. TRIM optimizes this behavior in every case.
However, good SSDs reduce missing TRIM commands in using sufficient spare blocks, and sophisticated algorithms try to guess which blocks contain invalid data and may shift their contents less in other blocks.
The comparison of TRIM garbage collection (GC) is incorrect, and the statement "TRIM is a command implemented in the OS and erases cells that are no longer in use." is incorrect.
TRIM does not delete anything, but only marks as deleted. Deleting still does the Garbage collection of the SSD. The GC works closely together with the wear leveling and tries to create as many free cells, and spreads the use of the individual cells on the entire plate.
However, only those cells from which the SSD controller knows that they are empty or no longer in use, will be included in this GC mechanism.
If the system (or the user) deletes a file without TRIM, no more required cells are going on the journey across all blocks. Quite unnecessarily. This means that at each optimization of accesses to the SSD, tons of invalid data is moved. The GC can not be so sophisticated, it inevitably fails because the GC has to rely on for information, which blocks contain invalid data.
Without TRIM the SSD must wait until the operating system requires a specific block for writing, which already contains data. Only then the SSD knows that the data in this block are not needed. TRIM optimizes this behavior in every case.
However, good SSDs reduce missing TRIM commands in using sufficient spare blocks, and sophisticated algorithms try to guess which blocks contain invalid data and may shift their contents less in other blocks.
The Samsung SM951 is starting to ship to OEMs. It's the successor to the XP941 and is about 30% faster. I have found a dealer taking orders already but won't post any links in case it's a dud.
Without TRIM, free space inside a partition/filesystem is not really free. If you fill the drive even once, then that space always appears in use to the GC. The GC has no way of knowing (without TRIM) that the data is not valuable.
Some filesystems will write data all over the partition, even if the drive never fills up. For example, when looking for a large contiguous space to write a file, that might go anywhere on the partition.
If your partition is 960GB, then only the 110GB hidden by the drive is truly free. The 40GB that is free in the filesystem is not useful for the GC unless you have TRIM.
Let me suggest
On the long run either TRIM or serious overprovisioning is indispensable.
Enterprise drives intended for RAID often hide large amounts of NAND to help the garbage collector.
For example, I have about a dozen Intel 400GB PCIe SSDs for cache and transaction logs. The drives really have 550 GB of NAND, but are over-provisioned by 150GB.
It's well known (e.g. http://thessdguy.com/2012/10/how-controllers-maximize-ssd-life-over-provisioning/) that overprovisioning is good for the GC and minimizes the harmful effects of not having TRIM. You just have to make sure that the overprovisioned space is not accessible to the OS.
In the example below, I have a 160GiB partition on a 250GB SSD, leaving about 64 GiB inaccessible to the OS. (This was created on the factory new drive, so I know that the 64GiB has never been touched.)
Because this system uses TRIM, the 48GiB or so of free space in the filesystem is effectively part of the overprovisioning, although this number varies depending on how full the drive is.
Attachments
Dunno about any of that. I do know, empirically, my drive has been full the the brim (at least 960GB worth) and GC has taken care of it and it gives me full speed writes. Maybe I've been very fortunate and magic elves have snuck in at night taking care of my drive. But there's no TRIM on it. It's the OWC accelsior drive btw. And fact is, it gets full speed writes all the time. So whatever is going on in the, granted, POS, sand force controller wrt GC, at least that part is working well.
And stop splitting hairs with the OS doesn't issue the erase. Jesus, the point is it requires the OS to manage stuff on the drive instead of the drive being self managed. And that's what makes TRIM suck. Particularly when you have apple being asshats about not letting any drive (but theirs) benefit from trim.
The OS does not "manage" anything on the drive, it simply issues a notification to the drive at the point that the OS manages the space allocation.
Somewhere in the filesystem code there's logic like:
Code:
sts = mark_blocks_as_free (partition_handle, start_block, number_of_blocks);To support TRIM, it becomes something like:
Code:
sts = mark_blocks_as_free (partition_handle, start_block, number_of_blocks);
if (trim_enabled (partition_handle))
send_trim_notification (partition_handle, start_block, number_of_blocks);Nothing is managed - an advisory notification is sent to the drive using information that is already at hand.
Seems like a problem with Apple, not with the industry standard TRIM APIs.
Um, dude, that is the definition of management. It's notifying of the event, and directing the drive to the right spot. If that's not management, nothing is.
On this part, we can wholeheartedly agree.
If it's "management" - it's extremely lightweight. TRIM doesn't require any persistent state or metadata to be managed, either on the drive or on the filesystem.
"Seems like a problem with Apple"
On this part, we can wholeheartedly agree.
We can close the discussion on that...
Then why not each cell should work on its own, but GC is bad?
What's the point to have a SSD? Work in a computer!
Will you ever run a modern computer without SSD / HDD, CPU, OS....? If not, then all these components should work as a team to achieve maximum performance. If the OS (TRIM) + SSD combination can make both of them perform better, then why don't take the synergy? Which provide a win win situation to both SSD and the OS.
If you will ever take your SSD out, play it on the street like what you do to your mobile phone. Then I agree that the SSD should able to handle everything on its own.
Of course You can run the SSD without TRIM, but there is nothing to support that a SSD can run better without TRIM. Only the other way around.
Last edited:
Um because the operating system has to support it well and the operating system companies don't know squat about how to pave a drive well enough. A good example is what is happening to us with apple not supporting any drives but their own.
From a philosophical and design point of view, it's HORRIBLE design not to make devices that are self contained abstractions. What if some of the memory management code is in the memory and some in the processor. What if some of the math calculation code were in the FPU and some in the a graphics coprocessor. What if some of the code for sorting contacts is in your mail program. What will you have, chaos because as some programs update, not only might they break the other program for which they have code, but now as other systems work with the either the broken code or other broken app, they will fail. And all those other programs may equally have problems till the point the system is a big turd. It's a stupid design not because it works on a computer, which is what you changed the premise to, its stupid because it's not a self managed device that works with a computer.
So, in your opinion, all computer's components (GPU, USB controller, optical drive, etc) should contain it's own driver, and the OS should not do anything, or provide any driver (software support) to those devices. Isn't it?
Obviously we have different point of view. I treat the whole computer as one device, so it is self contain everything it need, including TRIM. I personally against "The Apple way of supporting TRIM", but not against TRIM.
I don't know if there will be any better SSD internal solution to replace TRIM. However, at this moment, even though TRIM is a horrible and stupid idea. It's still better to use it. "Is TRIM horrible?" and "Should we use TRIM?" are 2 different matters. There is nothing can replace this "stupid" and "horrible" function yet. And this "horrible" solution which actually really make a SSD perform better under a modern OS.
You can say TRIM is bad, this is your opinion. You can against it and don't use it. However, you can't change the fact that TRIM helps both the SSD and OS to perform better.
The "perfect" is the enemy of the "good"
There's a bit of a contradiction here....
Why do you think that "TRIM is a horrible and stupid idea" but you're not against it?
______
I think that TRIM is a simple and elegant solution to solve some of the problems of garbage collection, and that an SSD can run faster and longer if the OS gives it some hints about which data is no longer being referenced and can be freely garbage collected.
The history of computing is full of examples of where a "whole system" approach has been the most productive/cost-effective means to the end - look at "cache coherency" and NUMA and hyper-threading and multi-core and SMP (and...) as examples of when the OS can get much better performance by paying some attention to the characteristics of the hardware.
The ideal world "Ivory Tower" approach that each layer should be independent and communicate through opaque APIs with the layers above and below is very elegant - but not practical in many cases.
Device drivers by and large are written in C (not C++, not Java, not Python) - because they need to be fast and precise. (For the drivers that are written in C++, most of them could be trivially converted to C - they aren't using the full abstractions of C++.)
____________________
I feel that the "TRIM is gross" argument comes from people who've never done device driver or file system coding, and want to try to fit things that they don't understand into an "Ivory Tower" ideal concept of software layering.
The real world isn't that clean and pretty. Except for Apple OSX, the real world is working with a fine API for improving the performance and longevity of SSDs that are interfacing to filesystems written for traditional block storage devices. (And that API is evolving as areas for improvement are seen - with some systems even supporting TRIM with RAID-0, RAID-1 and RAID-10.)
In the future, we'll move beyond block storage interfaces (look up NVMe), but for now TRIM is the state-of-the-art.
There's a bit of a contradiction here....
Why do you think that "TRIM is a horrible and stupid idea" but you're not against it?
______
I think that TRIM is a simple and elegant solution to solve some of the problems of garbage collection, and that an SSD can run faster and longer if the OS gives it some hints about which data is no longer being referenced and can be freely garbage collected.
The history of computing is full of examples of where a "whole system" approach has been the most productive/cost-effective means to the end - look at "cache coherency" and NUMA and hyper-threading and multi-core and SMP (and...) as examples of when the OS can get much better performance by paying some attention to the characteristics of the hardware.
The ideal world "Ivory Tower" approach that each layer should be independent and communicate through opaque APIs with the layers above and below is very elegant - but not practical in many cases.
Device drivers by and large are written in C (not C++, not Java, not Python) - because they need to be fast and precise. (For the drivers that are written in C++, most of them could be trivially converted to C - they aren't using the full abstractions of C++.)
____________________
I feel that the "TRIM is gross" argument comes from people who've never done device driver or file system coding, and want to try to fit things that they don't understand into an "Ivory Tower" ideal concept of software layering.
The real world isn't that clean and pretty. Except for Apple OSX, the real world is working with a fine API for improving the performance and longevity of SSDs that are interfacing to filesystems written for traditional block storage devices. (And that API is evolving as areas for improvement are seen - with some systems even supporting TRIM with RAID-0, RAID-1 and RAID-10.)
In the future, we'll move beyond block storage interfaces (look up NVMe), but for now TRIM is the state-of-the-art.
Last edited:
It is my opinion. And I don't use it. And the GC works great that I don't miss it a all and best of all I don't have to F' with the operating system like you will when you get a 3rd party drive.
That said, is TRIM better than nothing, yep. So I actually agree with your first position (minus the bitchy tone towards me) in so far as, it sucks, but, for most people there are no alternatives, so you pretty much have to use it.
My point is that with 7% overpovisioning and GC, you basically don't need trim, at least on the drive that I've been using, and I"m going to look for another drive like it when 2+TB solutions come out. That, and I wish driver makers would further develop GC to be even better so that TRIM can be left behind (that or some other technological solution comes out not requiring 3x wipes on SSDs for an erase, and all this becomes moot).
There's a bit of a contradiction here....
Haha, sorry for my poor English. I personally love TRIM and don't think its stupid and horrible. However, "even though" it is, we still better to use it.
Do note that your drive is 12.7% overprovisioned, even when using the full 960GB.
Haha, sorry for my poor English. I personally love TRIM and don't think its stupid and horrible. However, "even though" it is, we still better to use it.
No problem - it makes sense now.
TRIM really needs to be added to the base SATA spec (which looks like it's in progress.) That way Apple can't implement or claim to support SATA without supporting TRIM for any drive on that bus.
Doesn't necessarily solve the PCI-E drive issues.
If TRIM had been added to the SATA spec when it first came out, we wouldn't be here. So when I say it's a hack of a solution, I mean it's not part of the SATA spec, therefore it's a hack on SATA.
It's been in the specs a long time - it was even revised back in 2011:
As for PCIe SSD blades, when in AHCI mode those implement the SATA command set - so TRIM is well defined for them.
Last edited: