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.
Doesn't implement the standard? What the fuck, lazy kernel developers. STOP FORCING YOUR NON-STANDARD COMPLIANT SOFTWARE ON US. Standards exist for a reason you know.
Guess it's only "OMG TEH STNDRDZ" when MS does it.
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).
What kind of retarded shitholery is that?
Nobody cares.
If someone loosely related to Ubuntu or Canonical does something or say something unpopular, then it's on the front page of every tech website.
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.
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
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?
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
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.