×

Announcing: Slashdot Deals - Explore geek apps, games, gadgets and more. (what is this?)

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!

Ubuntu Wants To Enable SSD TRIM By Default

Soulskill posted about a year ago | from the getting-into-fighting-trim dept.

Ubuntu 135

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."

Sorry! There are no comments related to the filter you selected.

jargon keeps me alive (1)

turkeydance (1266624) | about a year ago | (#45468165)

acronyms, too.

Re:jargon keeps me alive (1)

Anonymous Coward | about a year ago | (#45468177)

acronyms, too.

Yes. Thank gods for the 'right click Google ... ' feature!

Re:jargon keeps me alive (0)

Anonymous Coward | about a year ago | (#45468209)

You must feel positively immortal after reading /. today.

Re:jargon keeps me alive (0)

Anonymous Coward | about a year ago | (#45468705)

acronyms, too.

I dumped Ubun(dle)tu. An operating system for those who want shop, surf and browse the web for things to purchase--blows.

I say.......... (2)

Dega704 (1454673) | about a year ago | (#45468191)

Well it's about time.

Re:I say.......... (2)

ArcadeMan (2766669) | about a year ago | (#45468203)

No, it's about TRIM.

Re:I say.......... (0)

Anonymous Coward | about a year ago | (#45468735)

Well it's about time.

I'm always ready for a little trim. --

Re:I say.......... (2)

TheGratefulNet (143330) | about a year ago | (#45469751)

embarassing that it took THIS long. seriously embarassing.

only about 4 years late. sigh.

if they used systemd... (0)

Anonymous Coward | about a year ago | (#45468235)

it would be a both a config option and build time requirement.

Doesn't implement the standard???? (-1)

Anonymous Coward | about a year ago | (#45468247)

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.

Re:Doesn't implement the standard???? (1)

viperidaenz (2515578) | about a year ago | (#45468393)

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.

Re:Doesn't implement the standard???? (4, Insightful)

dreamchaser (49529) | about a year ago | (#45468413)

More like Linux doesn't follow the best practice recommendations of the standard when it wouldn't be all that hard to do so.

Re:Doesn't implement the standard???? (-1, Troll)

viperidaenz (2515578) | about a year ago | (#45468453)

I guess so, but I don't really care. I'm typing this on a machine running Windows 7 with an SSD TRIM'ing to its hearts content.

Re:Doesn't implement the standard???? (0)

Anonymous Coward | about a year ago | (#45468553)

Seriously? What relevance is that on an Ubuntu thread??

Re:Doesn't implement the standard???? (0)

Anonymous Coward | about a year ago | (#45469401)

Marketing and competitor bashing.

Microsoft's main products now.

Re:Doesn't implement the standard???? (0)

Anonymous Coward | about a year ago | (#45470803)

cool story bro

Re:Doesn't implement the standard???? (1)

Anonymous Coward | about a year ago | (#45468673)

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?

Re:Doesn't implement the standard???? (-1)

Anonymous Coward | about a year ago | (#45469237)

It's because they haven't learnt that polish is important not only on the front, user-facing side of things, but also vitally important on the behind-the-scenes area.

I guess it needs to be repeated - Linux is NOT a suitable desktop operating system for most people. This is because they continually fail to get the back-end parts of the kernel/system properly set even with distros that are supposedly desktop-focused. The fact TRIM is still not enabled by default when an SSD is detected shows that they don't know what they're doing. It makes you wonder what other optimizations are not being done but are done in Windows.

I dunno. Maybe people at Canonical and the like have realized that they'll never outdo Windows on the desktop and kinda got lax at trying to improve the experience. Either way, it doesn't encourage me to try to convert to Linux anymore. Fuck it's disappointing how Linux distros fail to keep up.

Re:Doesn't implement the standard???? (2)

jones_supa (887896) | about a year ago | (#45470951)

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.

Re:Doesn't implement the standard???? (2, Funny)

Anonymous Coward | about a year ago | (#45469411)

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.

Re:Doesn't implement the standard???? (5, Informative)

sexconker (1179573) | about a year ago | (#45468607)

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.

Re:Doesn't implement the standard???? (1)

viperidaenz (2515578) | about a year ago | (#45468951)

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.

Re:Doesn't implement the standard???? (0)

Anonymous Coward | about a year ago | (#45469531)

The word you are looking for is execute. TRIM needs to be implemented on both sides of the equation.

A step in the right direction (3, Interesting)

Cantankerous Cur (3435207) | about a year ago | (#45468249)

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'.

Re:A step in the right direction (1)

Anonymous Coward | about a year ago | (#45468331)

Who gives a fuck?
I run "unfriendly" FF, Chromium and Opera on a Samsung 830 here.
No discard, no tuning, it also contains a swap partition.
3.2TB written and 98% remaining life after 15 months.

It's cache (2)

tepples (727027) | about a year ago | (#45468367)

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.

Re:It's cache (3, Informative)

PhrostyMcByte (589271) | about a year ago | (#45468987)

The reason mobile browsers discard pages rather than write them to disk is that they use flash memory. Unlike a SSD which has expensive chips and lots of them, able to spread the writes around and implementing a RAID for speed, the flash in your phones and tablets is a lot more like a microsd card: rather low bandwidth and less useful write cycles.

Writing to disk on purpose (2)

tepples (727027) | about a year ago | (#45469129)

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?

Re:Writing to disk on purpose (2)

JanneM (7445) | about a year ago | (#45469307)

Firefox Mobile (at least the tablet Beta) has a "reader" mode for that. You see a small "book" icon in the address bar; it makes a "book" style reflow of the site without a lot of the navigation cruft for easier reading, but if you long-press it, it will also save the document for later offline reading.

Re:Writing to disk on purpose (1)

cerberusss (660701) | about a year ago | (#45470577)

I use instapaper, pocket or some other offline reader for that.

Re:It's cache (1)

timeOday (582209) | about a year ago | (#45470195)

Why do you say that? According to this guy [thinkdigit.com] , passmark scores 44MB/s read / 157 MB/s write on the iPhone 5s, which is very impressive. I am skeptical of the strange imbalance though, but according to the actual passmark website [iphonebenchmark.net] , the 5s earns 19,288 DiskMarks. I don't know what a "DiskMark" is, but for comparison the iPhone 3G scored 586 diskmarks, so the "disk" in the 5s is 33x faster. For sure it's not just a soldered-on MicroSD.

Re:It's cache (1)

CadentOrange (2429626) | about a year ago | (#45470963)

You can now buy SDXC cards that have 90MB/s transfer speeds, so it's not impossible that it's just high speed flash. SSDs on the other hand are capable of 400MB/s transfer speeds, 800MB/s if it's one of the new PCI-e devices found in the new MacBooks.

Re:A step in the right direction (0)

Anonymous Coward | about a year ago | (#45468541)

Disable the disk cache?

Re:A step in the right direction (0)

Anonymous Coward | about a year ago | (#45468963)

Do it yourself manually. about:config Disable disk cache in firefox. Jack up the mem cache.

firefox writes nearly nothing.

Re:A step in the right direction (1)

JanneM (7445) | about a year ago | (#45469269)

I put tmp and the Firefox cache on RAM. It really makes an enormous amount of difference in overall system responsiveness. More RAM and an SSD really are a lot more important than CPU speed for general-use machines.

Re:A step in the right direction (1)

hairyfeet (841228) | about a year ago | (#45470321)

Preach brother! I have tried just about every browser out there and frankly they ALL suck when it comes to writes, it doesn't matter how much RAM you have either it'll just keep pounding the drive. I mean when I have 8GB of RAM on my netbook there really isn't any excuse for touching the drive until browser close yet the one program that will keep my drive pounded is the browser. Even my audio editing in audacity doesn't seem to hit the drive as much as looking at simple web pages, and that is with ABP and flashblock!

Here's a solution... (1)

bayankaran (446245) | about a year ago | (#45471083)

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.

What the fuck? (0)

Anonymous Coward | about a year ago | (#45468255)

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.

Re:What the fuck? (5, Informative)

dshk (838175) | about a year ago | (#45468567)

TRIM is essential for maintaining SSD performance.

This is not so simple.

The original TRIM command is non-queued. It can kill drive performance on servers, so enterprise drives are designed to work well without TRIM. If you want better, and more importantly consistent performance then you should overprovision the drive. Overprovisioning means that you do not partition 20-40% of a new drive (or a used drive, after a secure erase). Those blocks will never be used, therefore the drive always have plenty of free space, so there is no need for trim.

Queued TRIM command appeared only in the SATA 3.1 specification, so only new drives support it.

Re:What the fuck? (0)

Anonymous Coward | about a year ago | (#45468985)

Relevant and correct info on /., what has the world come to?

Re:What the fuck? (1)

magamiako1 (1026318) | about a year ago | (#45470179)

This isn't quite as accurate. Most SSDs these days are built with space already overprovisioned. For example, a 128GB SSD might actually have 160GB of NAND flash inside of the device, with the remaining flash unreachable by the operating system and is used by the device.

Essentially, the age old adage of "over provisioning" is not actually that necessary on modern systems.

Re:What the fuck? (0)

Anonymous Coward | about a year ago | (#45470351)

This is simply not true.

SSDs for quite a while have had a hidden overprovision. Today's 120GB and 128GB SSDs have 128GiB of flash, resulting in 13% or 7% spare areas, respectively.

To overprovision further, one might only create a 100GB partition, resulting in 27% unused space.

For some workloads, there are serious benefits to having more unused space. How "modern" the system is has nothing to do with it - if anything, flash has become less reliable the more "modern" it gets.

Re:What the fuck? (4, Informative)

subreality (157447) | about a year ago | (#45470291)

Those blocks will never be used, therefore the drive always have plenty of free space, so there is no need for trim.

It's not quite that simple either.

SSDs write in pages, but erase in blocks of pages. When a page is changed it gets rewritten to another block. The original page is marked as free, but it can't be erased until the whole block is free. Therefore the SSD performs garbage collection of free pages, re-packing them into complete blocks.

On its own the SSD only knows which pages it freed during rewrites - it doesn't know about pages that COULD be freed because they're deleted. Overprovisioning prevents blocking when there are no free pages (that's a huge win), but the drive still wastes lots of time and wear-life moving deleted data around during GC. TRIM provides the necessary hint to prevent that waste.

Re:What the fuck? (1)

TheRaven64 (641858) | about a year ago | (#45471043)

It's also worth noting that there are two modes for TRIM. One enforces the invariant that two reads of the same block will give the same value if there are no writes between them, the other only requires this invariant for blocks that have not been marked as erased. There's often a performance difference between them, because the latter lets the drive just leave the block as spare and overwrite it during a GC and then reallocate it on write (a good implementation would mark it as zero'd and always return zeros until there is a write, but this requires slightly more space in the remapping tables and so isn't always done). It sounds like Linux is still using the former version, which can be very slow on some drives.

Can someone dumb-down the comment... (1)

Daniel Hoffmann (2902427) | about a year ago | (#45468301)

to Computer Science graduate? You know, down from kernel hacker?

What? I still count as a nerd and this IS news for nerds...

Re:Can someone dumb-down the comment... (5, Funny)

Feyr (449684) | about a year ago | (#45468321)

TRIM makes your new flash toys go weeeeeeeee, instead of them going only wee

Re:Can someone dumb-down the comment... (5, Informative)

tepples (727027) | about a year ago | (#45468441)

Solid-state drives (SSDs) [wikipedia.org] are an alternative to hard disk drives using flash memory instead of spinning platters. This greatly improves read speeds but doesn't do quite as much for write speeds. One reason is that each sector on a solid-state drive can only be erased a finite number of times before it starts failing. For this reason, the microcontroller in an SSD perform wear leveling [wikipedia.org] to spread writes across more physical sectors. TRIM [wikipedia.org] is a feature that an operating system can use to notify a drive that a range of sectors has become unused, which helps wear leveling run more efficiently. A cron job [wikipedia.org] is a program that runs periodically in the background, and Canonical (the publisher of Ubuntu, a distribution of the GNU/Linux operating system) wants to add a cron job that scans attached drives for unused sectors and sends TRIM commands for these sectors. It's possible for an operating system kernel to send a TRIM command for multiple ranges of sectors, but the current version of Linux doesn't know this and instead sends one range at a time. This slows down deleting files because the kernel has to notify the drive of each sector range as the file is deleted. To work around this missing feature of Linux, the cron job will TRIM when a drive isn't busy doing something else.

Re:Can someone dumb-down the comment... (2)

Lennie (16154) | about a year ago | (#45470793)

This isn't about Linux kernel not being smart enough, it's about crap SSDs that have horrible performance when TRIM is used during normal operations. So Linux can't use it during normal operations.

Re:Can someone dumb-down the comment... (2, Insightful)

Anonymous Coward | about a year ago | (#45468487)

A filesystem just notes which blocks are erased, it doesn't actually erase them. A flash based disk would normally keep maintaining the contents of erased blocks, since it doesn't know which blocks are still in use and which are not. Due to the way flash memory based disks work, keeping the contents of erased blocks causes significant overhead. Flash memory is erased and written in big blocks, so to write just a small sector, an SSD has to read a big block, modify it and write it back. This read-modify-write cycle causes so-called write-amplification, where writing a small amount of data actually causes much more data to be (read, erased and then) written to the flash memory. This is the reason why some disks are fast initially but become much slower once the entire capacity has been used once. With TRIM, the OS can tell the disk which blocks are no longer needed, so that the disk can treat them like empty blocks and not copy them in the read-modify-write cycle. (It's actually more complicated, but that's the idea.) The criticism is that the Linux kernel uses TRIM inefficiently (it uses many individual calls instead of combining several discontiguous erased blocks into one TRIM call.)

Poor man's TRIM (1)

tepples (727027) | about a year ago | (#45468521)

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?

Re:Poor man's TRIM (1)

dgatwood (11270) | about a year ago | (#45468573)

Because that would not cause the underlying flash page to be erased, which means it would not improve performance later, when the flash controller runs out of pre-erased pages and has to start erasing pages on the fly during the write operation.

Re:Poor man's TRIM (0)

Anonymous Coward | about a year ago | (#45468665)

To make it work, the disk would have to look at every written block and see if it's "the empty block". With this method, you'd transmit huge amounts of data over the bus and have the disk compare every byte just so that the disk knows which blocks are empty. Then it would treat empty blocks like unused blocks. But why would you do that? You have to modify the OS anyway, because as I mentioned earlier, file systems don't usually erase blocks, so the disk would not benefit from detecting empty blocks unless the OS specifically writes them. So you either add a TRIM instruction or an instruction to overwrite empty blocks. TRIM is faster and easier.

Some drives choke on TRIM (1)

tepples (727027) | about a year ago | (#45469075)

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 [slashdot.org] , 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.

Re:Some drives choke on TRIM (0)

Anonymous Coward | about a year ago | (#45469737)

Don't buy broken SSD drives. Seriously.

Re:Poor man's TRIM (1)

Cley Faye (1123605) | about a year ago | (#45468623)

Because the drive itself have no concept of filesystem, and wouldn't know what some specific patterns means. 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". So, no way for the drive to know where there is actual unused space.
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.

Re:Poor man's TRIM (0)

Anonymous Coward | about a year ago | (#45468701)

As long as the drive returns the same data that was written, it doesn't matter whether the data is actually read or generated because the disk only remembered "empty block". The actual reason for using TRIM instead of overwriting erased sectors with zeros is that telling the disk "blocks 1234865 to 19651281 are unused" is much faster than writing gigabytes of zeros.

The drive would decompress it (1)

tepples (727027) | about a year ago | (#45469089)

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?

Re:The drive would decompress it (0)

Anonymous Coward | about a year ago | (#45469551)

I don't have the URL, but there is floating out there an article about using NTFS recovery tools on a plain old hard disk versus a SSD. Needless to say, a FDISK got data back on the hard disk, and on the SSD, bunches of zeroes and the bare fs index tree.

Re:Poor man's TRIM (1)

ultranova (717540) | about a year ago | (#45468961)

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?

Why go to the trouble of implementing a command implicitly when you can implement it explicitly and avoid unintended side effects? Not to mention operating systems would still need to change the way they handle the disk to support the 0xFF method, and it would take up bandwidth needlessly.

Secure deletion (0)

tepples (727027) | about a year ago | (#45469111)

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 [slashdot.org] .

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.

Re:Secure deletion (3, Informative)

Anonymous Coward | about a year ago | (#45469691)

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 [slashdot.org] .

What in the fuck, you seriously consider some dude's admitted speculation as proof that this is a real risk?

Here's some vastly more likely semi-informed speculation: Like most modern standards, SATA has many optional features, and standardized discovery methods to inform software what each device can and cannot do. If a drive says it doesn't support TRIM (or, to be more precise, lacks some new capability tag which says it can do TRIM), the OS simply never issues a TRIM command.

It's like you (and that Immerman dude) have no concept of how sane people design protocols to safely accommodate future extensions.

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.

Which operating system would that be? I'm not aware of any mainstream OS which even tries to implement secure deletion at the kernel level. I know of exactly one (OS X) which implements it in a user-visible way at all, and there it's just an option to "secure empty" Trash (read: it overwrites file contents in place). This is really not very secure since it is 100% userland code which has no way of tracking all the blocks ever occupied by that file and scrubbing them all -- it can only scrub blocks currently occupied by the file. It can defeat casual attempts to recover file contents, but there aren't any guarantees.

But it's worse than that. Let's say you tried to write an OS For Paranoids which, at the kernel level, scrubbed all blocks as the file was deleted or as they ceased to be part of a file. This still would not be truly secure. ATA (and other abstract block device protocols like SCSI) implements semantics somewhat like this: "If you read block N, you'll get back whatever was last written to block N, or undefined data if N was TRIMmed and not subsequently written to". There is absolutely no guarantee that the device did not make invisible, unaddressable extra copies of the contents of block N behind the operating system's back. As a matter of fact, SSDs frequently do just that -- it's required if you're going to implement effective wear leveling. Even HDDs frequently leave invisible copies of old data behind whenever they have to spare out a bad sector. Merely overwriting blocks is not, and never has been, a true guarantee that the contents are actually gone from storage media.

This is why good SSDs implement the ATA Secure Erase command, which (if implemented according to spec) truly erases 100% of the media, including all overprovisioned space, any invisible copies of old data which it may contain, and so on. But wait, oh mah gawd that's another new command- HOLY SHIT IT WILL NEVER WORK BECAUSE NOBODY CAN EVER ADD NEW THINGS TO A STANDARD!!! why did I not see this before?!

Tepples, please, for the sake of my sanity, please consider no longer arguing endlessly with posters who are explaining how shit works in the real world. Next time, instead of succumbing to the temptation of raising objection after objection based on your ideas about how things ought to work, consider the possibility that those ideas are naive and wrong.

Re:Secure deletion (1)

cmurf (2833651) | about a year ago | (#45470503)

Any file system supporting "secure" deletion should be filling deleted files' sectors in the background anyway.

You don't seem to understand the basics of how SSD's work or you would haven't said this. Such secure file deletion doesn't actually work on SSDs. The LBA's overwritten with zeros or random data are written to different, already erased physical pages, while the original pages containing the data are simply flagged for erase. It isn't possible to directly overwrite SSD pages. They have to be erased first.

Re:Poor man's TRIM (1)

TheGratefulNet (143330) | about a year ago | (#45469773)

every byte from 00 thru ff is a valid data byte. writing what you think is a 'code' is still just data.

trim tells the drive that there is NO data on this sector. ...if we had 257 binary codes that bit inside an 8bit byte, we would not need trim ;)

Re:Poor man's TRIM (0)

Anonymous Coward | about a year ago | (#45470833)

Irrelevant. When you read from trimmed sectors, you get 0x00 ...

Re:Poor man's TRIM (1)

wonkey_monkey (2592601) | about a year ago | (#45470783)

Why couldn't an operating system just write a big block of 0xFF bytes to an unused sector

My desktop background is a white .bmp, you insensitive clod!

Re:Poor man's TRIM (0)

Anonymous Coward | about a year ago | (#45470967)

The thing is, though... An empty flash page contains 0xFF anyway, so it should work still. Even if the page is not mapped, if the controller implemented "page of 0xFF = trim", it would know to return a page of 0xFF when it gets a request for an unmapped page.

Re:Poor man's TRIM (1)

Lennie (16154) | about a year ago | (#45470795)

The SSD can't treat 0xFF as empty because 0xFF could be part of a file.

Re:Poor man's TRIM (1)

TheRaven64 (641858) | about a year ago | (#45471065)

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). You're thinking of an SSD as if it were a big RAM chip, full of blocks of flash with a simple addressing scheme. It isn't. It's a load of flash cells, which wear out over time, and a very complicated controller that maps blocks to cells. The point of TRIM is not to erase the block, it is to remove the block from the remapping tables so that that the wear levelling knows it has an unused block that can be erased whenever it makes sense to do so. The erasure happens on a cell granularity, and cells are some multiple of the block size (not sure what they are these days, probably 64-128KB). Knowing that all blocks in a cell are free is great, because the controller can then erase the entire cell. Knowing that only one block is in use and it hasn't been modified for a while means that it can defragment by erasing one cell, moving the individual infrequently modified blocks to that cell, and then add their old cells to the free list for erasure.

Re:Can someone dumb-down the comment... (5, Informative)

dgatwood (11270) | about a year ago | (#45468559)

Quick terminology note: Flash storage is divided into large blocks, commonly called pages (to avoid confusion with disk blocks). Each page contains many disk blocks.

Flash storage has an interesting property in that you can change individual bits in only a single direction (either from 0 to 1 or 1 to 0, depending on the flash type). To change it in the other direction, you must wipe an entire flash page, which means rewriting the contents of a large number of blocks. To avoid a high risk of a power failure causing the loss of data that wasn't even changing at the time, the flash controller does not do the erase and rewrite in place. Instead, it rewrites the entire page in a different physical location (with an updated copy of the changed block or blocks), and then atomically changes the block or page mapping so that the blocks are now associated with the new physical page. It then erases the original page so that it can be reused during a subsequent write operation.

This need to erase and rewrite has a side effect, however. As the flash drive gets more and more full, it eventually runs low on pages that can be erased ahead of time, because eventually every block on the disk has had something written to it at some point in the past, even if that block is no longer actively being used by any actual file. The disk does keep some spare pages around, but that only goes so far towards fixing this problem. This means erasing pages during the write operation itself, which is a much slower operation than writing to a pre-erased page. Many of those pages, however, may contain only data that is no longer relevant—blocks from files that were deleted a long time ago. Therefore, if the flash controller could somehow know that it is safe to pre-erase those pages ahead of time, they could be ready to go when you need to write data to them.

Unfortunately, it isn't practical for a flash controller to understand every possible file system, which makes that somewhat difficult. To solve this problem, they added a new ATA command, called TRIM. The operating system sends a TRIM command to tell the flash controller that the blocks within a certain range are no longer in use by the filesystem, which means that the flash pages that contain those blocks can be pre-erased for fast reuse.

Well done, linux (0)

Anonymous Coward | about a year ago | (#45468315)

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).

Wait, it's not already? (-1)

Anonymous Coward | about a year ago | (#45468333)

What kind of retarded shitholery is that?

Evil Canonical does something useful (-1)

Anonymous Coward | about a year ago | (#45468341)

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.

Several years too slow (3, Informative)

readacc (3401189) | about a year ago | (#45468349)

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!?!

Re:Several years too slow (2, Informative)

Anonymous Coward | about a year ago | (#45468401)

I really don't know about windows TRIM support, but It'd better do it only if the HDD supports it. For this it requires HDD specific drivers. Or at least a complete list of drives that support TRIM. This isn't necessarily available to all linux distros.

About the wake-on-lan thing, I can only say that on lenovo systems, it's possible to take-over the system by wake-on-lan in the default configuration (because you can boot from dhcp/tftp by default). So I'm pretty glad they didn't enable this by default. Sounds more like a well-thought choice than a missing feature.

So imho, those distros chose some very good defaults, especially for your usecase.

Where TRIM is unsupported (1)

tepples (727027) | about a year ago | (#45468475)

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?

Re:Where TRIM is unsupported (1)

Immerman (2627577) | about a year ago | (#45468621)

I don't have the spec in front of me, but my bet is one of two things:
1) The command is recognized in it's entirety by the drive as being an unrecognized command, and either ignored or reported to the OS as an error.
2) undefined behavior (This *probably* does not include your hard drive animating and going on a homicidal rampage. Probably.)

Now, how much do you want to bet that all the old HDDs out there properly recognize the TRIM command as invalid and fail gracefully?

Re:Where TRIM is unsupported (0)

Anonymous Coward | about a year ago | (#45468683)

It gets more fun. Some early SSDs *claim* to support TRIM but choke on it.

Re:Where TRIM is unsupported (1)

0123456 (636235) | about a year ago | (#45469767)

It gets more fun. Some early SSDs *claim* to support TRIM but choke on it.

Fortunately, those early SSDs have mostly expired from other firmware bugs or write lifetime by now.

Re:Where TRIM is unsupported (0)

Anonymous Coward | about a year ago | (#45470997)

Depends on what the stupid engineer decided to use the not yet defined command for, instead of using the "reserved for internal use" commands.

One drive model reportedly used it for firmware update. No magic numbers, no checksums, just fire off the TRIM command, followed by the new firmware.

These drives were bricked when used with a Linux distro that enabled TRIM by default. That taught the distros to not enable TRIM by default.

Re:Several years too slow (1)

BronsCon (927697) | about a year ago | (#45468569)

If the drive doesn't support it, it just discards the command. There's no reason not to do it. Period.

Re: Several years too slow (0)

Anonymous Coward | about a year ago | (#45469449)

About the wake-on-lan thing, I can only say that on lenovo systems, it's possible to take-over the system by wake-on-lan in the default configuration (because you can boot from dhcp/tftp by default). So I'm pretty glad they didn't enable this by default. Sounds more like a well-thought choice than a missing feature.

So... a system will PXE boot by default and the security concern is the ability to remotely turn the computer on??? Are you fucking serious? Is the machine supposed to otherwise stay off forever on this rogue boot server infested network?

Re:Several years too slow (0)

Anonymous Coward | about a year ago | (#45468419)

You should be submitting detailed suggestions directly to the distribution developers instead of whining on /.

Increase suggestion quality for busy developers (3, Insightful)

tepples (727027) | about a year ago | (#45468489)

I imagine that discussing the suggestions on Slashdot first is a way to avoid presenting half-baked suggestions to busy developers.

Re:Increase suggestion quality for busy developers (0)

Anonymous Coward | about a year ago | (#45468643)

I imagine that discussing the suggestions on Slashdot first is a way to avoid presenting half-baked suggestions to busy developers.

Very true. If anything the audience here can usually validate an issue and provide a reasonable level of impact to vet kernel or distro changes, or at least find out it's not just them going batshit crazy on a particular problem.

Re:Several years too slow (0)

readacc (3401189) | about a year ago | (#45469155)

No point. The launchpad pages for Ubuntu are full of legitimate bug reports that never get fixed or even addressed/confirmed. Canonical just don't have the manpower to manage a desktop operating system like Microsoft does.

I've grown tired to writing scripts to manually enable things that a distro could have implemented themselves if they just fucking TRIED once in a while. But they don't, because Unity is more important to them than actual backend improvements. Remember, the shiny is more fun to work on.

Re:Several years too slow (1)

jones_supa (887896) | about a year ago | (#45471109)

Yes.

What really hits my nerve is the bug which causes the brightness to be adjusted in double steps on laptops.[1] [launchpad.net] [2] [launchpad.net]

The brightness change event is probably processed by two recipients. Maybe the OS grabs it and does the adjustment but lets the event to be handled by BIOS too. Or maybe there are two handlers for the event inside the Ubuntu power management system.

Anybody, see it for yourself. Install Ubuntu on a laptop and wank the brightness up/down. On most laptops it goes two steps. Usually this temporary workaround fixes it:

# echo 'N' > /sys/module/video/parameters/brightness_switch_enabled

This should be basic Quality Assurance stuff...

Re:Several years too slow (2)

c0lo (1497653) | about a year ago | (#45469779)

Windows 7 incorporated TRIM support for SSDs back in 2009.

And, to date, it stays the same: only for SATA drives [wikipedia.org] .

Re:Several years too slow (1)

Lennie (16154) | about a year ago | (#45470801)

I encounter many Windows systems that don't enable Wake On Lan on almost a daily basis. So I wouldn't be so sure.

Oversimplification in the article (4, Informative)

adisakp (705706) | about a year ago | (#45468495)

"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... (0)

Anonymous Coward | about a year ago | (#45468509)

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.

Re:Nice to see... (1)

cbhacking (979169) | about a year ago | (#45468601)

Still my preferred Linux distro for desktop productivity (where the important points are A) easy to tell it what I want it to do, and B) it does it well, without needing a lot of hand-holding but also without needing me to fix anything afterward). Backtrack (I suppose I should really upgrade to Kali now...) and FreeBSD in VMs, for work and play respectively.

It's not enabled by default?!?! its 2013!! (0, Troll)

citylivin (1250770) | about a year ago | (#45468531)

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 [askubuntu.com]

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.

Re:It's not enabled by default?!?! its 2013!! (4, Informative)

Microlith (54737) | about a year ago | (#45468633)

Linux fully supports TRIM and failure to enable it will not damage the device in any way. What will happen is the device will slow down and spend more time freeing blocks as-needed if the drive is increasingly full.

Of course, if your SSD is your boot drive and you have /home elsewhere, chances are you aren't going to suffer and current drives are significantly faster than older ones (and at their worst, still significantly faster than rotating media.)

Re:It's not enabled by default?!?! its 2013!! (1)

Anonymous Coward | about a year ago | (#45469721)

> osx and windows both support it for YEARS

So you've proven yourself an irrational Linux-hater. Why are you here?

With my MacBook, here is what I had to do to enable TRIM:

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

With my work laptop that is a Dell, I had to download a utility from Intel to enable TRIM:

https://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=18455

Care to apologize for your lies?

Re:It's not enabled by default?!?! its 2013!! (1)

magamiako1 (1026318) | about a year ago | (#45470167)

There is nothing you do special in Windows to enable TRIM support. It is included support directly in the OS and the drivers, automatically. The only time you have to do anything special in Windows for TRIM support is when you're actively using Intel SSDs in a RAID configuration using the Intel Rapid Storage Driver--and even that is merely a driver update, and boom, RAID0 TRIM support passed from OS to driver to device.

That's it. Under all other circumstances TRIM is automatically enabled and there are no extra utilities needed under any circumstances.

Re:It's not enabled by default?!?! its 2013!! (1)

TheRaven64 (641858) | about a year ago | (#45471107)

And TRIM is enabled by default on OS X if you use the stock drives. If you use an after-market replacement then you do need to explicitly enable it (which sucks). With FreeBSD, it's enabled for UFS by default since 9.0 and ZFS by default since 9.2. It is also enabled in software raid configurations by default in 10.0. I'm very surprised Linux doesn't enable it by default.

Re:It's not enabled by default?!?! its 2013!! (1)

cmurf (2833651) | about a year ago | (#45470557)

What the hell reason would it not be enabled by default?

a.) Because the spec was poorly written making the command a non-queuing command, therefore file systems can't just spit out a series of TRIM commands every time a file is deleted because the queue has to be cleared first. This slows down everything, reads and writes. With multiple file systems per drive, a given file system doesn't necessarily know the drive is idle so some other process would need to do the delayed TRIM which is what Canonical is suggesting.

b.) Some manufacturers have implemented very aggressive erase cycles upon TRIM commands being received and that stalls the drive also. This is also not very smart.

I just assumed, since osx and windows both support it for YEARS, that forward thinking linux did. Wow.

OK OS X only supports it for Apple branded drives, it's disabled for most (maybe all) 3rd party SSDs. No doubt Apple found certain edge cases where it was causing a problem and instead of white or blacklisting piles of drives they decided not to let manufacturers use users as guinea pigs. Conversely, Microsoft decided it's probably better than not doing it and after all the manufacturer's and their industry trade association and standards body need to sort out this mess rather than being bailed out of it.

Already part of my Ubuntu setup routine. (1)

Flammon (4726) | about a year ago | (#45469021)

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.

Re:Already part of my Ubuntu setup routine. (1)

magamiako1 (1026318) | about a year ago | (#45470187)

In Windows, when I perform a delete operation, the TRIM command is automatically sent along with the DELETE operation command. No scheduled tasks needed.

Re:Already part of my Ubuntu setup routine. (1)

magamiako1 (1026318) | about a year ago | (#45470205)

Adding to this:

http://blogs.msdn.com/b/e7/archive/2009/05/05/support-and-q-a-for-solid-state-drives-and.aspx

"Windows 7 requests the Trim operation for more than just file delete operations. The Trim operation is fully integrated with partition- and volume-level commands like Format and Delete, with file system commands relating to truncate and compression, and with the System Restore (aka Volume Snapshot) feature."
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?