Ubuntu Wants To Enable SSD TRIM By Default 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."
jargon keeps me alive (Score:2)
Re: (Score:1)
acronyms, too.
Yes. Thank gods for the 'right click Google ... ' feature!
I say.......... (Score:3)
Re: (Score:3)
Re: (Score:3)
embarassing that it took THIS long. seriously embarassing.
only about 4 years late. sigh.
A step in the right direction (Score:3, Interesting)
Re: (Score:1)
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.
Re: (Score:1)
In the 13 months I've used mine, I've written 3.8 TB. It estimates the total lifetime for my SSD at little under 9 years. But, honestly, why reduce this number if you don't have to?
To make a parallel here, properly inflated tires for your car save 1-2% gas mileage. Literally pennies in gasoline per tank. But again, why waste?
It's cache (Score:3)
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 f
Re:It's cache (Score:4, Informative)
Writing to disk on purpose (Score:3)
Re: (Score:3)
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: (Score:2)
I use instapaper, pocket or some other offline reader for that.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Or if it's an OCZ Revo drive which is also an PCI-e device that's been around for years.
Re: (Score:2)
Re: (Score:3)
Apple traditionally uses raw NAND flash for the phones - this gives them the advantage in that the controller is all theirs in the SoC and any performance issues likewise are in their control rather than use eMMC which you're dependent on the controller and flash array.
Re: (Score:2)
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: (Score:2)
Here's a solution... (Score:2)
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
Re:What the fuck? (Score:5, Informative)
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: (Score:2)
Essentially, the age old adage of "over provisioning" is not actually that necessary on modern systems.
Re:What the fuck? (Score:5, Informative)
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: (Score:2)
Re: (Score:2)
Those blocks will never be used, therefore the drive always have plenty of free space, so there is no need for trim.
Clue me in: how in the world does the drive firmware know which blocks the filesystem data structures have pointers to as valid, currently unused ranges?
Re: (Score:2)
Can someone dumb-down the comment... (Score:1)
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... (Score:5, Funny)
TRIM makes your new flash toys go weeeeeeeee, instead of them going only wee
Re:Can someone dumb-down the comment... (Score:5, Informative)
Re: (Score:3)
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: (Score:2)
Even on non-crap SSDs it's better to do this in batches rather than in tiny fragments every time a sector gets freed.
Re: (Score:2, Insightful)
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-writ
Poor man's TRIM (Score:2)
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: (Score:2)
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.
Some drives choke on TRIM (Score:2)
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 dr
Finding unbroken SSDs (Score:2)
Re: (Score:2)
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.
The drive would decompress it (Score:2)
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: (Score:2)
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
Secure deletion (Score:1)
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: (Score:3, Informative)
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 Immer
Re: (Score:1)
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: (Score:2)
Such as? The post you linked to explicitly said they were simply guessing.
On the other hand, compression algorithms do have plenty of weird side effects, from increased latency to randomly varying write speeds to the impossibility of estimating actual free space - because for every bit a lossless compression algorithm shaves off one file, it must add to some other file (because if a bigger
Re: (Score:2)
for every bit a lossless compression algorithm shaves off one file, it must add to some other file
Pigeonhole principle. I'm aware of that.
Thus some files are actually made bigger than their size implies.
By about one byte, a marker that the sector is uncompressed. In a real file system, this overhead of one byte per sector is made up for by real files that contain real redundancy, such as the last sector of a file (or the only sector of a small file). On average, the last sector of a file will contain a run of half a sector's worth of $00 bytes. This and other cases where sectors can be compressed allow more logical sectors to fit into a single erase page.
Re: (Score:2)
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: (Score:2)
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: (Score:2)
Well except for the error detection/correction bits. That would be the difference.
Re: (Score:2)
The SSD can't treat 0xFF as empty because 0xFF could be part of a file.
Re: (Score:2)
Re: (Score:2)
It's not the same because you are forgetting that even sectors with long runs have error detection/correction bits at the end, and a TRIM will make them 0x00 (or technically, SSD trimed pages are written with all bits on, so 0xFF). In order to be able to (likely) quickly reuse that sector again, it must first be erased setting all bits on, then written by turning off selected bits. Writes can only change bits from 1 to 0, which is quick, and does not degrade the life of the sector. Erasing it however, is
Re: (Score:2)
Block-level RLE (Score:2)
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.
Re: (Score:2)
is as good as TRIMmed
Negative. See any of the above explanations as to why.
Re: (Score:2)
Re:Can someone dumb-down the comment... (Score:5, Informative)
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.
Several years too slow (Score:3, Informative)
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: (Score:2, Informative)
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. Soun
Where TRIM is unsupported (Score:2)
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: (Score:2)
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: (Score:2)
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: (Score:2)
Re: (Score:3)
Windows 7 incorporated TRIM support for SSDs back in 2009.
And, to date, it stays the same: only for SATA drives [wikipedia.org].
Re: (Score:2)
I encounter many Windows systems that don't enable Wake On Lan on almost a daily basis. So I wouldn't be so sure.
Optimizations are trade-offs (Score:2)
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
Increase suggestion quality for busy developers (Score:4, Insightful)
Re: (Score:2)
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 tempor
Oversimplification in the article (Score:5, Informative)
"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.
It's not enabled by default?!?! its 2013!! (Score:1, Troll)
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 affair
Re:It's not enabled by default?!?! its 2013!! (Score:5, Informative)
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: (Score:2)
Linux fully supports TRIM and failure to enable it will not damage the device in any way.
Linux does not fully support TRIM. It is the very reason why many distros do not automatically enable "discard" in fstab. As noted in the summary: "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".
Re: (Score:1)
> 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: (Score:2)
That's it. Under all other circumstances TRIM is automatically enabled and there are no e
Re: (Score:2)
Re: (Score:1)
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 a
Re: (Score:3)
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.
Why would a filesystem need to know? On FreeBSD, the filesystem just spits a BIO_DELETE command into the GEOM layer, and it is up to GEOM to schedule when to dispatch it - it's free to reorder it, as long as it doesn't move it after a BIO_WRITE with an overlapping range. If the filesystem needs to know about the status of other filesystems then that's a serious layering problem. The FS should not be making the decision about whether to send the BIO_DELETE, because it's the responsibility of something low
Already part of my Ubuntu setup routine. (Score:2)
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: (Score:2)
Re: (Score:2)
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."
Re: (Score:2)
Hence the performance hit in Windows. Sounds similar to discard mount option [wikipedia.org], something that I didn't want because of the performance hit while I was working. I'd much rather keep my system snappy when I'm using it and trim the drives when I'm not.
Re: (Score:2)
There is a much higher performance hit by not "trimming" your drive. And if this isn't enabled by default, it means a vast majority of Linux users out there with SSDs are experiencing significant performance degradation that they don't even know about.
Re: (Score:2)
If you read the source for the information on the 'performance hit' issue, It looks like Windows 7 is not performing the TRIM command in the same manner for which there was a performance hit with the 'mount -discard' option when using ext4.
"Also, it was assumed 9 months ago that Windows 7 did it that way. But
since then one of the kernel devs got a sata protocol analyser and
monitored how Windows 7 is doing it. Not l
Re: (Score:2)
Yes, when you compare it the mount discard option, which is why I avoided it. A daily trim job will however give you much better performance which is what Windows 8 is doing now. Not sure about Windows 7.
Trimming on the fly, whatever the implementation, will always slow you down more during use than batch trimming when the system is idle.
Re: (Score:2)
Windows 8 still includes the TRIM operation on deletes. It also includes the TRIM in the new 'defrag' tool.
The defrag tool isn't sending TRIMs, the file system is. The file system sends TRIMs for clusters that get freed for any reason. One reason a cluster would get freed is of course the file gets deleted. But another reason is that the file gets defragged. Say there's a request from the defrag tool to move a particular file VCN from LCN1 to LCN2. Then in the same transaction LCN2 gets allocated by
Re: (Score:2)
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???? (Score:5, Insightful)
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: (Score:1)
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: (Score:2, Funny)
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: (Score:3)
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: (Score:2)
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.
Re: (Score:2)
Windows does this for hard disks too.
Re:Doesn't implement the standard???? (Score:5, Informative)
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: (Score:2)
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: (Score:3)
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. C
Re: (Score:2)
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 par
Re: (Score:2)
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.