Slashdot Mirror
Ubuntu Wants To Enable SSD TRIM By Default
jones_supa writes "During the first day of the latest virtual Ubuntu Developer Summit, Canonical developers finally plotted out the enabling of TRIM/DISCARD support by default for solid-state drives on Ubuntu 14.04. Ubuntu developers aren't looking to enable discard at the file-system level since it can slow down delete operations, so instead they're wanting to have their own cron job that routinely runs fstrim for TRIMing the system. In the past there has been talk about the TRIM implementation being unoptimized in the kernel. Around when Linux 3.0 was released, OpenSUSE noted that the kernel performs TRIM to a single range, instead of vectorized list of TRIM ranges, which is what the specification calls for. In some scenarios this results in lowered performance."
acronyms, too.
Well it's about time.
it would be a both a config option and build time requirement.
I'm still waiting for for firefox or chrome to make themselves SSD friendly. I know we all have RAMdisk, but I swear, after the OS, web browsers seem to generate the next highest number of 'writes'.
The question here is - why the hell is TRIM not enabled in Ubuntu already? The idea of a cron-job fstrim has been around as long as TRIM-for-Linux itself. Canonical should have done this years ago, I can't believe they are only just starting to discuss this now, when SSDs are commonplace. TRIM is essential for maintaining SSD performance.
to Computer Science graduate? You know, down from kernel hacker?
What? I still count as a nerd and this IS news for nerds...
Hell yeah, I'm trim'ing live for some time now, even through a luks/dmcrypt layer. Works smoothly. Followed http://wiki.ubuntuusers.de/SSD/TRIM#TRIM-mit-Festplattenverschluesselung (german).
Windows 7 incorporated TRIM support for SSDs back in 2009. I know the Linux kernel can do it with the right mount options and has been able to for some time, but after a while you just assume distros are setting things automatically as expected (there's very few situations where TRIM is a bad idea, particularly on a desktop-focused distro like Ubuntu).
There's a reason I still feel like using a poor-man's system when using Linux on the desktop. They just don't think hard enough about automating stuff. Heck, Ubuntu (and no other distro I believe) doesn't enable Wake-on-lan when you shutdown, whereas Windows 7 and onwards does. This is something you have to script in yourself. Why the fuck aren't distros doing things you can reliably expect in commercials operating systems!?!
I swear, after the OS, web browsers seem to generate the next highest number of 'writes'.
I'd bet a lot of these writes are for caching received HTTP response bodies to disk. Otherwise, desktop browsers in low-memory environments would have to act like Firefox for Android and Chrome for Android. When I open multiple pages in tabs in these mobile browsers, they tend to discard entire pages as soon as I switch to another tab and reload them when I switch back. This interferes with my common use case of opening multiple pages in tabs and then reading them while offline and riding transit. Firefox for X11/Linux can keep pages open on a Dell Inspiron mini 1012 laptop with 1 GB of RAM, but Firefox for Android can't on a first-generation ASUS Nexus 7 tablet with the same amount of RAM. I guess the difference comes from two differences in the environment: swapping is more acceptable on X11/Linux than on Android, and desktop browsers are more likely to keep things in disk cache than mobile browsers.
Of source it doesn't implement the standard because it's a OS kernel, not a hard drive.
The drives implement TRIM, Linux just doesn't take full advantage of its capabilities.
More like Linux doesn't follow the best practice recommendations of the standard when it wouldn't be all that hard to do so.
I really don't know about windows TRIM support, but It'd better do it only if the HDD supports it.
What happens when the kernel sends a TRIM command to a drive that does not recognize TRIM commands?
I imagine that discussing the suggestions on Slashdot first is a way to avoid presenting half-baked suggestions to busy developers.
"As long as that SSD doesn't stall trying to pull blocks off the top of that queue, it really doesn't matter how deep it is. So if you have 10GB of free space on your partition, you only need to call wiper.sh / fstrim once every 10GB worth of file deletions."
This isn't necessarily true. Earlier Trim will improve the performance of the SSD drive because the drive knows more free space -- more free space allows the drive to 1) pre-emptively erase flash 2) coalesce fragmented blocks 3) more efficiently combine write blocks 4) perform wear levelling operations with less overhead.
Early trimming can have a similar effect to the manufacturer increasing slack space which increases performances on nearly all SSD's.
Nice to see the SuSE Linux guys keeping their eyes on the ball. It is (at least used to, haven't been using linux in a while) a good distro, and clearly it has some bright people working on it.
A filesystem just notes which blocks are erased, it doesn't actually erase them. [...] With TRIM, the OS can tell the disk which blocks are no longer needed, so that the disk can treat them like empty blocks
Why couldn't an operating system just write a big block of 0xFF bytes to an unused sector, which the SSD's controller would compress into an efficient representation of a low-information-content sector, instead of needing a dedicated command?
What the hell reason would it not be enabled by default? I dropped an SSD in my webserver at home a year ago. I just assumed, since osx and windows both support it for YEARS, that forward thinking linux did. Wow.
Now i have to go check tonight when I get home with this article as a reference
http://askubuntu.com/questions/18903/how-to-enable-trim
I am shocked and appalled. We all laughed 10 years ago when M$ said installing linux may damage your hard drive, but in this case its true! What a sad state of affairs.
As a potential lottery winner, I totally support tax cuts for the wealthy
Seriously? What relevance is that on an Ubuntu thread??
Of source it doesn't implement the standard because it's a OS kernel, not a hard drive.
The drives implement TRIM, Linux just doesn't take full advantage of its capabilities.
The drive does shit (shit that you don't get to know the details about) when issued a TRIM command.
The OS is responsible for sending that TRIM command.
TRIM tells the drive when data is deleted, allowing the drive to do whatever it thinks is best when writing pages of data or erasing blocks of data.
Without TRIM, the drives considers all previously written data to be valid because it doesn't know about deletions (they're done at the logical level within the file system).
TRIM enables your drive to have much more flexibility when writing (and overwriting) data, and when load balancing and garbage collecting. It also reduces the need for load balancing and garbage collecting.
All decent modern SSDs support TRIM for good reason. All decent modern OSs should as well.
Now if I could just get Intel to enable TRIM on RAID 0 for my chipset (1 generation behind the cutoff), I'd be set.
I'm surprised this is still being figured out. I thought TRIM was old-hat, long since turned-on by default and working as intended.
So it's off by default because the Linux implementation slows regular IO, and even when it's on it's sub-optimal due to lack of multiple trim ranges.
Microsoft has had this working in Windows 7 circa 2009. With multiple trim ranges.
WTF? SSDs are important Linus. What is the major malfunction here?
The drive does shit (shit that you don't get to know the details about) when issued a TRIM command.
My point exactly. the drive implements the standard. Not the OS.
I already setup a cron job to fstrim my drives so this is a welcome addition that will save me a step during new installations.
ayottesoftware.com
To make it work, the disk would have to look at every written block and see if it's "the empty block".
A lot of flash controllers already use compression of some sort to reduce write amplification. So a controller could just store which sectors compress to the smallest sizes. That wouldn't be much more effort than storing which sectors are TRIMmed, and it'd ensure a well-defined response when the kernel attempts to read a TRIMmed sector.
TRIM is faster and easier.
Unless, as Immerman pointed out, a particular drive chokes on it. Sending TRIM to a device that doesn't correctly support TRIM produces "undefined behavior", and even some drives that claim to support TRIM don't in fact. No drive chokes on constant fill.
A sector full of only 0xFF might mean "I don't need this anymore" as well as "this file have a sector worth of 0xFF stored there".
Either way, when you read that sector back, the drive would decompress it to a string of 0xFF. This is true whether it's an "empty sector" or a row of white pixels in a BMP file.
Using trim, the FS/OS/whatever's on the line can tell the drive "ok, this part I don't need anymore, go play with it" in a non-ambiguous way.
What happens when the kernel attempts to read back a sector that hasn't been written since it was last TRIMmed?
Why go to the trouble of implementing a command implicitly when you can implement it explicitly and avoid unintended side effects?
Because the explicit command causes unintended side effects in drives manufactured prior to the command's introduction.
Not to mention operating systems would still need to change the way they handle the disk to support the 0xFF method
Any file system supporting "secure" deletion should be filling deleted files' sectors in the background anyway.
I'm aware of that. But what should I do if I want the browser to write the page to flash memory, such as if I'm about to go offline for an hour?
Microsoft's main products now.
WTF? SSDs are important Linus. What is the major malfunction here?
There was a fully functioning implementation on its way into the kernel, but Linus lost it when his only copy of the code was lost because his SSD failed.
The word you are looking for is execute. TRIM needs to be implemented on both sides of the equation.
cool story bro
It makes you wonder what other optimizations are not being done but are done in Windows.
I'll toss in one: in Windows 8, an USB memory stick is automatically powered down if it is mounted but has not been in use for a while.
I moved all the cache directories of Firefox/Chrome/IE and even the temp directory of OS and all applications point to a cheap USB thumb drive.
I have not looked around to find out if there is more writes happening elsewhere other than cache/temp...but I guess a super majority is taken care of.
The above might be the reason the SSD did not 'disappear' when a power outage happened.
Now, as far as I know the only cache I cannot control is when the virtual machines are booted up - swap spaces remain in the SSD.
Tat Tvam Asi
The word you are looking for is API. An implementation is on the side of the thing that exposes the API. The OS uses the API, it does not implement the standard. Implement would mean providing the API. Not making use of an API doesn't mean you're not standards compliant. Eg. None of my OSs make use of (U)EFI (because coreboot is amazing). My OSs are following the boot standards, They just aren't using the API that was implemented for (U)EFI.
You "execute" TRIM through the API of its implementation. Calling it on delete is an optional part of the protocol. Not calling it on deletes is not deviation from the standard.
Windows 8, an USB memory stick is automatically powered down if it is mounted
Yeah, but in reality it gets it wrong half the time and closes Firefox instead.
Join the Slashcott! Feb 10 thru Feb 17!
Because that would require the flash to do deduplication and know that the blocks were full of FF and so could be copy-on-write (and, in your scheme, block-level compression)
Block-level run-length encoding is exactly what I had in mind. This way more logical sectors can be packed into one 64-128K erase page. A sector that has been compressed into "0x00, then 4095 more of the last byte" is as good as TRIMmed. It needs to be done anyway for file tails.
How should one make sure a particular model of SSD is not broken before buying it? I was under the impression that by the time all the bugs got shaken out of a product, it ended up close to EOL.
The "everything turned on by default" concept is part of why Windows is bloated and insecure.
This is changing, but part of what I like about Linux is that it makes less assumptions about what you are doing and assumes a (at least somewhat) skilled operator. Part of what I dislike about Ubuntu is that it makes too many assumptions about what I want to do. It's also why multiple Linux distros that target different audiences are a good thing.
The points here are that :
1. All optimizations or assumptions make something better for a certain task or use scenario.
2. Any optimization that makes something better for a certain task or scenario will be worse for a different task/use scenario.
Think of strong versus lightweight -- it's a tradeoff.
Competition Good, Monopoly Bad.
Windows does this for hard disks too.
The word you are looking for is API. An implementation is on the side of the thing that exposes the API. The OS uses the API, it does not implement the standard. Implement would mean providing the API. Not making use of an API doesn't mean you're not standards compliant. Eg. None of my OSs make use of (U)EFI (because coreboot is amazing). My OSs are following the boot standards, They just aren't using the API that was implemented for (U)EFI.
You "execute" TRIM through the API of its implementation. Calling it on delete is an optional part of the protocol. Not calling it on deletes is not deviation from the standard.
Holy shit no.
TRIM is a COMMAND, part of the ATA INTERFACE STANDARD.
Hardware devices IMPLEMENT this STANDARD to function. Operating systems IMPLEMENT this STANDARD to support said hardware.
API stands for APPLICATION PROGRAMMING INTERFACE. APIs allow for SOFTWARE to talk to SOFTWARE. APIs do not fucking apply here. TRIM is not part of an API. It is part of the fucking STANDARD. Whatever the drive does in its FIRMWARE doesn't make TRIM an API, nor does it mean the OS doesn't have to IMPLEMENT TRIM as part of the latest SPECIFICATION of the ATA STANDARD.
People like you are why manufacturers have to pay money and get certified to be able to slap a Windows or Mac sticker on their gear, and not the other way around.