![el capitan trim enabler el capitan trim enabler](https://www.ken-g.com/blog/wp-content/uploads/2016/11/mbp-ssd-trim.gif)
With fs_usage happily babbling away in one window, we pulled up a second terminal window and, using dd, created a ~50 megabyte file full of random gobbledygook: raptor:~ lee$ dd if=/dev/urandom of=tempfile4 count=100 bs=512kĥ2428800 bytes transferred in 5.597703 secs (9366128 bytes/sec) Because fs_usage will tell you lots and lots of things-far more than you usually want to know-we constrained its output to only file system activity with a flag: $ sudo fs_usage -f diskio To do this, we needed to create a file to figure out what logical blocks correspond to that file, check them for data, delete the file, flush the disk’s queue to make sure it executes any pending TRIM operations, and then check the (former) file’s blocks again to see if they’re empty.īut before we created the file, we needed a way to observe the file being written, so we used fs_usage. To set a baseline, we checked to see if TRIM was observable on a MacBook Air with an SSD from Apple. Using it, we were able to peek at logical block contents and catch TRIM doing its thing. Thomas Tempelmann’s iBored utility again came to the rescue. In a Linux distro with an EXT4 file system and the right kernel, you can use the hdparm command to sleuth its workings out, but unfortunately hdparm isn’t available on OS X even via Homebrew or Macports. To actually verify that it’s functioning, you need to be able to check on the contents of a file system logical block. Usually, if it’s working, you don’t really notice it at all-it simply helps the SSD keep its pool of spare pages as large as possible. TRIM (written capitalized not because it’s an acronym, but because it’s a command from the AT Attachment command set) is a hard thing to catch in action. This turned out to be a bit tricky to actively check, since it requires peeking under the hood into the file system-but this is Ars Technica, damn it, and this kind of stuff is what we do. We wanted to see if we could verify that TRIM was actively working on third-party SSDs in El Cap.
![el capitan trim enabler el capitan trim enabler](https://clevercm831.weebly.com/uploads/1/2/6/5/126593254/912093701.jpg)
One of the Macs we loaded El Cap on was an old 2007 Core 2 Duo iMac that had been upgraded with an SSD, and we enabled third-party TRIM on it with the trimforce command (introduced as a Yosemite feature in June 2015).
![el capitan trim enabler el capitan trim enabler](https://lh3.googleusercontent.com/-GeCkb33uTS8/Vzsn89cq0cI/AAAAAAABpzA/bYjHoKSq8Kcz1nUT5aEFpPvuu7zbELhIQCE0YBhgL/w560-h338/20160517_3.png)
If you’d like a whole deep-dive on not just TRIM but SSDs themselves, including a discussion of where TRIM fits into the processes by which SSDs keep themselves clean and operational, you can hit up our big SSD explainer. If you’d like more of a refresher on TRIM, you can check out our piece from April on whether or not TRIM is something you should care about. TRIM isn’t a mandatory thing, but it’s definitely nice to have. Without TRIM, the SSD has no way of knowing when the operating system deletes files, and the operating system has no way of telling the SSD (because typically, a "deletion" in a modern file system is actually just a quick write, not an actual-for-real zeroing-out of the deleted data). Further Reading Ask Ars: “My SSD does garbage collection, so I don’t need TRIM… right?”Īs a very quick refresher, TRIM is an ATA command that operating systems can cause to be issued to SSDs when files are deleted it tells the SSD that the blocks mapped to the deleted file can be marked as stale and cleaned for reuse during the next round of SSD garbage collection.