Talk:Trim (computing)

Operating system support not accurate

Article states PCI Express based storage doesn't support TRIM on Windows 7.

"PCI-Express SSDs that are different type of device"

That's not really true. Fusion-io drives are PCI Express based storage devices that support TRIM. maybe the writer meant PCI Express drives that present themselves as SCSI devices like the RevoDrive or maybe they were talking about Mini PCIe devices. that bit's sort of messy. — Preceding unsigned comment added by 174.25.105.96 (talk) 15:30, 24 November 2013 (UTC)

TRIM is a command or automatic?

Could someone please clarify among these options:

• TRIM happens automatically whenever you delete a file
• TRIM is a command occasionally issued by the operating system
• TRIM is a command issued manually

For example, if I ran windows XP for a month, then started up Linux with TRIM support, is everything going to be automagically TRIMmed? Anything? dfrankow (talk) 21:38, 31 January 2011 (UTC)

Note: http://www.ibm.com/developerworks/linux/library/l-kernel-advances/index.html has a great explanation of this: looks like it's a per-delete "discard request" for the freed blocks. dfrankow (talk) 22:43, 31 January 2011 (UTC)

cleanup

Working on the cleanup. Did a fairly large refactoring of the references. I'm not sure it's necessary to proceed further with the single-sourced citations, but community vote? Jimhsu77479 (talk) 04:27, 5 May 2010 (UTC)

• Happened to stop-in while researching SSD's, a started a bit of cleanup, too. [Cites, mostly.] Will follow-up with more. — DennisDallas (talk) 12:05, 17 March 2011 (UTC)

delete size

An SSD can only delete in half megabyte (512KB) blocks????

Something amiss there...

Care to elaborate? Or even better; change it yourself! (assuming something's wrong) CapnZapp (talk) 17:22, 12 October 2009 (UTC)

I've explained write amplification, the cause for this and added references. MichaelGoldshteyn (talk) 14:18, 15 October 2009 (UTC)

---

SSDs can write 4KiB blocks at a time, but, due to hardware limitations, they must delete larger blocks (e.g., 128KiB–512KiB).

That does not make much sense. If an SSD can write a 4KiB block it can also write a 4KiB block of zero bytes. This would effectively delete the block.

As I understand it the problem is that SSDs can not write blocks as small as 4KiB. They can only write larger blocks, say 128KiB. So if you want to write 4Kib, you have to read 128KiB, modify the 4KiB and write the whole 128KiB back. But if the controller knows that the 128KiB block is actually not allocated it can skip the reading part. —Preceding unsigned comment added by 213.47.42.142 (talk) 13:04, 22 January 2010 (UTC)

The best links I've found to explain these issues: Support and Q&A for Solid-State Drives, and White Paper: The TRIM Command. Mcavic (talk) 08:23, 24 January 2010 (UTC)

Efair (talk) 18:22, 2 April 2010 (UTC) I think the issue here has to do just with overwriting existing data. There's four things you might want to do to your storage (whether disk, tape, or SSD): A) initialize it, B) read from some area; C) Write data to a previously unused area, and D) write data to a previously used area. Bubble memory can't treat C and D equivalently. With bubble memory you can't change a one into a zero like you can change a zero to a one -- the former requires special processing, the latter does not -- and that special processing is several times more time consuming than B or C. It's such an exceptionally slow process with high overhead, that your perception of your SSD would probably be unfavorable if the manufacturer allowed you to perform it on small chunks of data. An analogy -- if you're going to drive a long way to the store, get everything in one trip -- even if you don't need it immediately -- because if you have to make two (or three or four) trips you won't be pleased with the result.

Based on the links I posted above, I understand it like this: say you were going to write your name in some sand on the beach, but the sand has footprints in it. You have to smooth out the sand before you can legibly write in it. And if you then want to correct one of the letters in your name, you have to erase your whole name and start over, because due to the nature of sand, you can't cleanly erase just one letter. Mcavic (talk) 05:10, 18 April 2010 (UTC)

An SSD (or any Flash memory device) can indeed write e. g. 4 KiB storage units (commonly known as "pages"), but only delete (commonly known as "erase") e. g. 512 KiB storage unity (commonly known as "blocks"). A "write" operation on an EEPROM is also called a "program" operation. A value is "programmed" into the page of an EEPROM. "Erasing" sets all bits (including control bits like parity, etc.) in a page to high (one). "Programming" can only "unset" bits, turning high-bits (ones) into low-bits (zeroes). Therefore, before you can write ("program") a new value into the page of an EEPROM, you must first "erase" the block containing that page, unless the value you need to write is a strict subset of the value that's already stored in that page, which means that the new value has zeroes wherever the old value has zeroes, but may contain additional zeroes. However, it may not contain ones in places where the old value contained zeroes, since "programming" can only turn ones into zeroes but not the other way round. As the new value to be written is normally not a strict subset of the value stored, especially not, when "auxiliary information" like parity bits come into play, an "erase" operation has to be performed before a page can be "programmed" again. "Programming" a page that already contains a value, so has already been "programmed", even if it has been "programmed" to store "all ones", will usually result in the page becoming "junk", resulting in a read operation on that page not to return the data that was intended to be stored there with the last "program" operation, often due to parity information becoming wrong and the memory then "error-correcting" the contents into "junk". However, this is not the only reason. Since "programming a page twice" is an undefined operation of most EEPROM memory chips, they may expose extremely weird behaviour on such operations, and might even behave in a non-deterministic way. 87.149.68.84 (talk) 00:09, 11 September 2014 (UTC)

What about reading trimmed regions ?

There is no source, but I know this four cases of reading result of such area:

1. such areas read as zero

2. such areas may return old data

3. such areas generate IO error during read operation

4. somebody said, that under his experiment such areas was read as 0xFF filled

This is very important, think about creating full image of such device.

I am not sure what you are asking, but your comments look related to "deterministic TRIM." In general the end user would not be worried about this because after the drive receives the TRIM command the LBA for those locations are identified as blank and waiting for garbage collection without needing to be saved. Any request from the OS to these locations will result in "zero" being sent back to the OS regardless of what was there before. If the user purposely uses a diagnostic command to directly read a location on the drive, it is possible that the diag command may be able to return the original content before it is garbage collected. If anyone can find a source for this we can merge it into the article. § Music Sorter § (talk) 23:05, 14 August 2010 (UTC)

A request form the OS to read a location that has been TRIMmed and awaits garbage collection is only guaranteed to return all 0s on deterministic TRIM. With regular TRIM there is no specification on what it should return. So it most likely returns all 0s, but can also return all 1s, or can return random garbage data. Which one of those happens depends on what the people who wrote the firmware for that drive decided. --Taltamir (talk) 04:39, 5 June 2012 (UTC)

Write Speed vs Erase Speed

I recently removed a statement that Erase operations were slower than write operations because it was misleading in the context of the paragraph. The source http://www.anandtech.com/show/2738/5 does state the erase operations typically take 2ms and write operations take about 800us, but the block erase operation works on 128 pages at one time, so to write a full block would take about (800us x 128 pages = 102.4ms) vs. 2ms. Therefore the erase operation is 50 times faster for the same amount of data. We can add this information to the page if someone wants to write it up, but it might be better to add to the Flash memory page instead. This article is on the TRIM command itself. § Music Sorter § (talk) 22:56, 14 August 2010 (UTC)

TRIM doesn't work on virtual disk services?

TrueCrypt doc says it "doesn't prevent" TRIM:

TrueCrypt TRIM support

Is there a reference for the statement "computer files can only be deleted completely or truncated at the end"? It seems overly broad; doesn't it depend on the file system?

It's completely implementation-dependant, even filesystems which don't have direct support for holes can be tricked to share an immutable empty block, which is backwards compatible as long as you don't write to it... --Ismael Luceno (talk) 06:17, 10 June 2011 (UTC)

Shortcomings - Inefficient on Fragmented drives (?)

I removed the following text from the main page because the source referenced has no support for the statement and to my knowledge it is not actually true. The source discusses the defragmentation command used on HDDs and never uses the term TRIM anywhere in the article.

• The TRIM command becomes inefficient on heavily fragmented drives due to the fact that filesystem clusters/fragments are smaller (usually 4 KB) than flash erase blocks (usually 512 KB). This problem is worsened by the fact that solid state drives using wear leveling cannot be defragmented .

§ Music Sorter § (talk) 06:17, 7 November 2010 (UTC)

References

Article should summarize that the TRIM command actually does

98.207.235.40 (talk) 21:34, 28 December 2010 (UTC)

• As mentioned above in "cleanup" section, I've found some decent sources/cites (esp. reputable Knowledgebase articles) that can clear up any confusion. Admittedly, I haven't digested the entire WP article, and have started with the lead paragraph and major points, but will check whether this Anon's fairly-recent point has been covered adequately. — DennisDallas (talk) 12:13, 17 March 2011 (UTC)

 Paragraph added § Music Sorter § (talk) 06:44, 22 June 2011 (UTC)

Non-vendor utilities

Commercial windows utilities for TRIM has started popping up (e.g. this press release). Should such utilities be listed?

Yes. Nothing about Trim is inherently limited to use by OSes, and this article should not exclude other uses. RossPatterson (talk) 18:14, 31 January 2013 (UTC)

Sparse Image TRIM Support

I'm curious if TRIM would encounter the same problems on "sparse" image files. Since these split disk images into blocks for easy incremental backup, it would seem that deleted blocks could be trimmed in much the same way as other files. If this is the case, should it be added to the section on disk images?

Zerocool3001 (talk) 22:20, 1 March 2011 (UTC)

OS X 10.6.8 adds TRIM support

I don't know how to edit html on the page, but this new information should probably be added.

http://www.macrumors.com/2011/06/27/mac-os-x-10-6-8-brings-trim-support-for-apple-ssds-graphics-improvements/

190.98.90.120 (talk) 22:29, 27 June 2011 (UTC)

We already have coverage for Lion supporting TRIM. Note that this source also states the support is only for Apple authorized SSDs. Not that it means they do not support TRIM in SSDs, but we may want to be more clear about this in the comments section if we believe this source is notable enough.

Support for TRIM has been included in OS X Lion since its early developer builds, but Apple has apparently decided to push the feature out to Snow Leopard users as well. The new native TRIM support does appear to limited to stock Apple drives, as users who have installed third-party SSDs into their machines have reported that TRIM is not enabled by the update.

§ Music Sorter § (talk) 08:37, 28 June 2011 (UTC)

Reason for undo of edits by Brycen

There were a few problems with the addition that would not have helped just to fix them. Saying writing all zeros, deleting the file, and then the OS will TRIM it in supported systems is not relevant to the section about getting TRIM functionality in an OS that does not support TRIM. The comment that some format utilities will write all zeros and some SSDs will not contribute WA for such sectors is pretty substantial without a source reference (and I am not sure that is even true). § Music Sorter § (talk) 00:46, 8 August 2011 (UTC)

List of SSDs supporting TRIM

I propose that trying to maintain this list will become insurmountable. The true control of the TRIM command is with the SSD controller in the SSD. Since there are less than 10 total manufacturers of these devices, that list would be easier to maintain. § Music Sorter § (talk) 05:54, 21 March 2012 (UTC)

Scheduled time window? Tracking amount of TRIM needed?

Is TRIMming something that can be scheduled to occur at a certain time of the day?

Assume a business with typical network servers that run 24x7, but the business is only open during the day, and runs a nightly backup from 10pm to 4am. Is it possible to somehow inform the SDD at 4:30 am to begin TRIMming as much as possible until 7:30 am, and then stop that activity before the business opens for the day?

Server responsiveness would be degraded during the scheduled period, but since the servers are mostly idle anyway, the degraded performance doesn't matter to anyone.

Is it possible to measure how much TRIMming an SSD needs to do?

This could apparently be a measurable statistic that a network administrator could use to determine if additional time is needed for a server SSD to clear the TRIM queue, such as allocating more time for TRIMming during other mostly idle parts of the day, or on weekends.

-- DMahalko (talk) 06:18, 9 October 2012 (UTC)

• TRIM is a SATA command sent by the operating system (if it supports it) to inform the SSD what LBAs are no longer holding valid data. With HDDs you did not need to tell the drive in advance because you could directly overwrite invalid data. SSDs with NAND flash memory require you erase a whole block of pages in order to re-write to a previously written page. If the SSD is garbage collecting invalid data, you waste flash endurance (P/E cycles) and time to move that data to new pages.

• Some SSD controllers perform garbage collection in the background when idle to speed up future writes, but it has the down side of rewriting possibly invalid data before the OS can TRIM it thereby losing another P/E cycle. Other SSDs perform garbage collection in the foreground as needed to prevent losing extra P/E cycles, but it has to be very efficient and fast to not cause the system to slow down. All SSD controllers today perform their garbage collection as they have best optimized their architecture and do not typically have end user or host system controls to alter it. § Music Sorter § (talk) 19:04, 3 December 2012 (UTC)

Some Operating systems have a separate command for trimming (e.g. fstrim in GNU/Linux) that can be run as a scheduled task, and is often preferable to online trim because it is often more efficient to bulk-trim free space at night than the wait for trim when deleteing files. Maybe the fstrim manpage could be a source for this when somebody wants to add it.91.89.241.155 (talk) 01:57, 18 August 2014 (UTC)

What stands "TRIM" for?

Is the term "TRIM" an abbreviation and if so, what is the long form? --91.6.84.229 (talk) 07:25, 2 December 2012 (UTC)

• TRIM is a SATA command like READ, WRITE, etc. It is capitalized when written because it is a command, not because it is an acronym.§ Music Sorter § (talk) 18:55, 3 December 2012 (UTC)

Move to Trim (computing)

Per WP:TITLEFORMAT, this article should be moved to "Trim (something or other)". I suggest Trim (computing). RossPatterson (talk) 18:20, 31 January 2013 (UTC)

Done. ViperSnake151  Talk  05:10, 29 August 2013 (UTC)

This move was justified with "WP:MOS/TM, not an acronym" However, it's not a trademark either, so WP:MOS/TM is irrelevant. "words are not capitalized unless they would be so in running text," says WP:TITLEFORMAT, and TRIM is capitalized in running text (look at the articles references, and the article itself, before the move). So, any reasons not to revert the move and this, both by ViperSnake? --Elvey (talk) 04:31, 26 September 2013 (UTC)

Zeroing

The obvious solution would be to zero the deleted blocks by a simple write, needing no special command set (it could even be done by a simple shell script in user space). Why has a special command been implemented? --88.74.159.200 (talk) 04:30, 15 August 2013 (UTC)

The point of TRIM is to tell the "disk" that a block is free for reallocation, not to erase the data it contains. RossPatterson (talk) 11:09, 15 August 2013 (UTC)

Well, naturally, but I sort of counted on the SSD firmware to get the hint. --88.74.129.208 (talk) 14:45, 15 August 2013 (UTC)

Put it this way: when I delete 100 4GB files, I really don't want to write 400GB of zeroes to the SSD :-) RossPatterson (talk) 23:10, 15 August 2013 (UTC)

This idea of writing zeroes seems important. When the operating system writes all zeros to a logical block on an SSD, the SSD doesn't have to write a physical block of zeroes somewhere and then point to it. Instead, the SSD can tag that logical block as unused, and stop pointing to a real block, thereby releasing the real block to the available pool. Overwriting an entire file with zeroes is a tedious way to release its storage space, as mentioned (400GB), but it's better than having no way to do it. Writing 400GB of zeroes would proceed at the maximum speed of the interface, because the SSD would only be unmapping logical blocks, not writing zeroes to any physical blocks. I think the drive manufacturers have figured this out. (Maybe extend it to any one-byte pattern like A5A5A5....) I think I have observed this on a USB memory stick. Writing all-zero blocks proceeded MANY times faster than writing non-zero blocks. Maybe I wrote zeroes, or maybe it was the Windows format command. A876 (talk) 00:14, 26 November 2013 (UTC)

TRIM irreversibly deletes the data it affects?

Certainly, that's the case for the DZAT variant of TRIM, but I'm betting the reason for the other variants is that often this is NOT true. The citation doesn't seem very credible to me; it reads as someone presenting an assumption as fact. If we knew which OSes use which variant of TRIM... Anyone? (Also, I'd bet that with most controllers, DZAT is slower than Non-deterministic TRIM. (this is just a staff post, but the thread makes me think my hunch is right.) --Elvey (talk) 21:58, 19 August 2013 (UTC)

No, DZAT guarantees no such thing, and suually doesn't. All that drives need to do is make sure you read back zero, the data doesn't have to be erased in flash, and with current generation drives, will almost cetrainly not be erased.91.89.241.155 (talk) 01:38, 18 August 2014 (UTC)

Identify Device bit confusion

The article says:

   Non-deterministic Trim: each read command to the LBA after a Trim may return different data. (SATA Word 169 bit 0)
   Deterministic Trim (DRAT): all read commands to the LBA after a Trim shall return the same data, or become determinate. (SATA Word 69 bit 14)
   Deterministic Read Zero after Trim (DZAT): all read commands to the LBA after a Trim shall return zero. (SATA Word 69 bit 5)

But word 169 simply says TRIM is available, it doesn't say anything about whether it is deterministic or not. Word 69 determines whether TRIM is deterministic or not iff trim is available. I also can't see DZAT in any ACS-2 draft - this seems to be added in ACS-3.

Likewise, you can't have both deterministic trim and DZAT, as the list implies - either you have deterministic trim only, or both, but you can't specify DZAT without deterministic trim with these bits.

It might also be worthwhile to find out where the DZAT/DRAT acronamys are from, as the ACS doesn't use this terminology.91.89.241.155 (talk) 01:37, 18 August 2014 (UTC)

I went on and removed the misleading references to the bits and reworded the text so it makes more sense.91.89.241.155 (talk) 01:46, 18 August 2014 (UTC)

SCSI

"SCSI provides UNMAP command (full analog of TRIM) and WRITE SAME (10,16) commands with unmap flag.[60]" Medium and Highend Storage arrays had thin provisioning features before TRIM was available, and *I think* those already had unmap to reclaim space. (Seen on EMC CX series in 2010. Veritas VxVM detected "thin" disks and could message back to the array about freed space.

But if that is the case it should not be stating that UNMAP was a analog of TRIM. 188.174.185.69 (talk) 08:49, 12 October 2014 (UTC)

Shingled Drives

Some conventional hard drives that use shingled tracks on rotating magnetic disks also support TRIM. This is used to avoid having to re-write unused data when a block of adjacent - overlapping - shingled tracks needs to be re-written. The exact mechanism is not identical to the one in SSDs but from an OS POV the use mechanism is the same. Should there be a note about that in here?

TRIM and Over-Provisioning on SSDs

I think it would be appropiate to relate these features since there is confusion as to whether they are similar or do the same purpose. A Trim vs Over-provisioning section would anwser these questions:

To the SSD controller, unallocated disk space is equivalent to TRIM space? Does it make sense to reserve unallocated space when using automatic TRIM on Windows/Linux to get best performance?

Hoping it is relevant, thanks. — Preceding unsigned comment added by Wyup (talk • contribs) 11:32, 30 October 2021 (UTC)