I disabled TRIM option and filled my SSD with random files so that there whould be no free space. However, when I deleted these files from bin and downloaded something else, I did it with no problem. Maybe I am wrong, but shouldn't there be an error, because whole space in SSD was still ocuppied due to TRIM disabled?
-
FWIW, you can verify/test this with something like blog.cy.md/2012/12/09/ssd-trim-check-tool– OrangutechCommented Sep 12, 2022 at 23:38
-
A moment's thought should make it clear that writes to a full SSD don't cause it to need any more space.– David SchwartzCommented Sep 13, 2022 at 21:27
-
1Your question implies that disks which don't support TRIM are one-time-writable, which is obviously not the case.– Dmitry GrigoryevCommented Sep 15, 2022 at 12:27
Add a comment
|
6 Answers
TL;DR: SSDs have more physical blocks than logical blocks, and all modern SSD firmware uses copy-on-write semantics whenever updating the contents of a logical block.
You’re misunderstanding how SSD firmware works.
SSD firmware differentiates between logical blocks of storage, and physical blocks of storage. The OS only sees logical blocks, not physical blocks, and at any given point in time each logical block maps to exactly zero or one physical blocks. On a properly functioning SSD, there are always more physical blocks than logical blocks (usually at least 10% more on a brand-new SSD).
Internally, the firmware tracks which logical blocks are in use, and which physical blocks those logical blocks map to. When the OS writes to a logical block for the first time, a physical block that is not in use gets picked by the firmware to store the data, and the firmware then records that new mapping of blocks. However, when the OS rewrites a logical block, instead of changing the physical block in-place, the firmware picks a new unused physical block, writes the updated data there, updates the block mapping, and then adds the old physical block to an internal list of physical blocks that need to be cleaned up.
This special handling is known as ‘wear leveling’ in this context, or more generally as ‘copy on write’. It’s done to prevent individual physical blocks of flash memory from wearing out too fast, because flash storage is write limited (the individual flash cells actually break down a tiny bit each time you write to them).
Most modern SSDs go a step beyond this, and track how many times each individual physical block has been written to, and then pick the free physical block that has been written to the least whenever they need to write data. However, that improved approach has one major limitation: the firmware has no way to know that a logical block is no longer in use, which means that a physical block that was part of a file that got deleted won’t be ‘freed’ in the firmware until it the logical block that maps to it gets written to again, so blocks that are otherwise ideal candidates to be rewritten may not actually get reused for a long time. You also can’t get around this by just wiping the contents of every file before it gets deleted, because that just leaves a different physical block stuck unused, which doesn’t really solve the problem.
This is where the ATA TRIM command comes in (as well as its equivalents in other storage protocols). It provides a way for the OS to tell the SSD firmware ‘Hey, I’m not storing any data here, you can go ahead and reuse this block.’. Notably however:
TRIM(and all the other equivalents) is mostly advisory. The firmware doesn’t actually have to do anything with the physical block, though in most usage the logical block that was trimmed will read back as all zeroes, all ones, or (less commonly) some fixed pattern of bytes.- For a couple of reasons, even when it’s supported,
TRIMis generally not invoked as part of the OS freeing blocks in the filesystem (be it for deleting a file, or for some other reason). In particular, older ATA SSDs did not support queuingTRIMcommands (which made such inline usage horrendously bad for performance), and some devices may force the operation to be synchronous even when queued (that is, things still have to wait for it to finish before it processes any other commands), which is almost as bad. TRIMdoes not guarantee removal of data on the physical media. Depending on the SSD, any data stored in the corresponding physical block may linger for an indeterminate amount of time up to however long it takes for writes to the device to result in that physical block being rewritten. However, the data in a region that has been trimmed is usually not recoverable without taking apart and rewiring the SSD or updating it to use custom firmware.
answered Sep 12, 2022 at 22:19
-
2"TRIM (and all the other equivalents) is mostly advisory." => not always. More or less reputable disks advertise the "Reproducible Zero After Trim" (RZAT) capability and at least some filesystem drivers actively use this capability where available.– fraxinusCommented Sep 13, 2022 at 14:24
No.
If you disable TRIM, the drive will erase unused space as necessary. It just won't do it in the background. This will generally slow your writes to a crawl.
-
14Without TRIM, the drive won't know what space is used or unused. It will only erase space on overwrites, not when it's unused. (Of course, drives have some over-provisioning so they can still handle overwrites when the entire logical capacity is full of data that the drive has to produce if a future read asks for it. The erase block size is larger than the write block size, so this spare capacity is necessary for that and wear leveling). Having the SSD firmware think it's "full" all the time does increase write amplification. Commented Sep 13, 2022 at 2:34
-
4@PeterCordes - sure, but I was answering on the same level as the question, keeping it simple.– TetsujinCommented Sep 13, 2022 at 6:49
-
7Being sloppy and misleading doesn't seem like a useful way to increase a confused beginner's understanding. I used more precise language to make it clear what I meant and what I was disagreeing with in this answer, but you could have said "the drive has some space capacity for remapping, and will erase space when overwritten." Or other ways of putting it which avoid "erase unused space". Without TRIM, space is only unused when it's part of the over-provisioning (physical not logical space) or when it's never been written. Commented Sep 13, 2022 at 9:09
-
3@PeterCordes - being simplistic is not the same as being sloppy. It really doesn't matter one bit how it does this, merely that it does. As far as the file system is concerned, the space is unused.– TetsujinCommented Sep 13, 2022 at 9:12
-
6@PeterCordes - I worked on the assumption that the answer should be on the same level as the question. That's all. If someone asked how to drive a car, you wouldn't start by explaining how you derive 95 RON. If you want to put in a hugely detailed answer, feel free. If you want to downvote this, feel free. Please, though, don't feel free to continue berating me in comments. Thank you.– TetsujinCommented Sep 13, 2022 at 9:32
It seems that you misunderstood how TRIM works.
The computer is allowed to write data to an SSD anywhere it wants and whenever it wants. That area doesn't have to be TRIM-med beforehand. Rewriting is completely okay, as it was with spinning hard drives.
What TRIM does is it notifies the SSD ahead of time that some area doesn't contain useful data anymore and whatever was stored there doesn't have to be maintained. This allows the SSD to erase it whenever it finds it convenient. That, in turn, releases that disk space to the free disk space pool, giving wear leveling mechanisms more room to shuffle data around.
SSDs are completely functional without TRIM - they may just be slower and have shorter lifespan due to inefficient wear leveling.
answered Sep 13, 2022 at 6:53
-
3@akostadinov: That's not correcting anything they wrote. They never said it had to erase it, just that it allows it. Your correction implies behavior that isn't typically observed; SSDs can only write to fresh pages, and must erase a block at a time (where a block is larger than a page). They usually respond to TRIM by coalescing and clearing blocks semi-eagerly; the alternative is eventually reaching the point where all pages are dirty, and any write requires reading in fragmented pages, clearing block(s), and writing out the fragmented pages before it can perform the requested write. Commented Sep 13, 2022 at 18:29
-
@ShadowRanger, I stand corrected. flash pages need to be erased before written to with most (all?) current technology. Thank you for pointing this out. Commented Sep 14, 2022 at 10:02
No.
TRIM is "deletion notify", in that the OS tells the drive "this area has been (logically) deleted" so that the drive can erase the data any time, usually in the background during idle times.
With TRIM disabled, the drive only knows that a block has been deleted when the next time it's written to. For SSD, it still has to do the usual cleanup: Find an empty page to write and update LPT (Logical-Physical translation Table) (if necessary).
When your drive is filled up with data, the SSD will find nowhere to write, so it has to erase some existing blocks. This results in slow writing speed, but NOT the inability to write.
On a side note, a Secure Erase on an HDD usually involves writing the whole disk with random data for multiple passes. With an SSD, however, I normally consider it secure enough to do a full-drive TRIM (blkdiscard) and leaving it powered for some time.
-
1
-
@TomYan Logical-Physical translation Table. Effectively synonymous to FTL.– iBugCommented Sep 13, 2022 at 5:05
Trim is not required to operate a SSD, but it can improve performance and longevity.
First some basics of SSDs. The first thing to understand is that nearly all SSDs used in desktops/laptops/servers are designed to be direct replacements for magnetic disks.
Unfortunately flash memory, while being very fast compared to magnetic disks has two undesirable characteristics.
- The block sizes for writing and for erasing are different, with the erase block size being rather large. The block sizes for erasing (a few megabytes last I heard, but may well be larger now) are much larger than the block sizes typically used by disk interfaces (512 bytes) and filesystems (4096 bytes).
- Erasing a block damages it slightly, this damage accumulates over time until the block becomes unusable.
To workaround these issues, the controllers inside SSDs seperate logical blocks seen by the host computer from physical blocks of flash memory, the raw capacity of the flash memory will always be a bit larger than the logical size of the drive to give the controller some room to work with.
Each time the host writes to a logical block, the controller allocates a physical block and writes the data. If the logical block was previously allocated to a physical block then the old association is broken and the old physical block becomes garbage.
As mentioned earlier, one eraseblock represents multiple read/write blocks. Some of those read/write blocks may be blank ready to receive new data, some of those blocks may represent logical data on the drive and some of those blocks represent garbage.
This creates a problem though, if we only erase an eraseblock when all of it's constituent blocks are garbage, then the controller is likely to run out of flash space as a large proportion of blocks build up a large proportion of garbage.
To avoid this the controller must perform "garbage collection", logical blocks are copied from eraseblocks containing garbage into clean eraseblocks. The original eraseblocks can then be erased, reducing the overall proportion of garbage in the flash array.
This garbage collection is a necessary but not particularly desirable part of the operation of a SSD controller, it takes up bandwidth that could otherwise be used to satisfy user requests and results in "write amplification" where the number of writes (and hence erases) seen by the underlying flash is greater than on the logical interface.
Another problem is that often some data on a drive is very static, with some logical locations remaining in place for years or even decades. If this data remained in the same physical locations then those locations would encounter no wear, while the frequently altered locations would encounter an above-average rate of wear. So from time to time a modern SSD controller will move highly static data around.
So how does this interact with filesystems? traditionally when you delete a file on a filesystem, the filesystem simply marks the blocks as free in it's own data structures, it does not inform the drive. The result is that there are a large number of blocks on the drive that are "garbage" as far as the filesystem is concerned, but valid data as far as the controller is concerned.
As you have discovered, this doesn't stop you deleting files and writing new ones. When you download the new files, the logical blocks are overritten, the act of overwriting a logical block frees up the old pysical block so it can be garbage collected.
However the greater the proportion of logical blocks that contain valid data, the more aggressive the controller must be about garbage collection to ensure that physical blocks remain available for new writes and the more static data the drive must move around for wear leveling purposes. So having a drive where the controller thinks nearly every logical block contains valid data makes the controller work at it's hardest.
And that is where TRIM comes into play, TRIM allows the filesystem to tell the drive that a logical block is now free. So the proportion of physical blocks that are allocated to user data comes back down and the controller can do it's work more easily.
-
The typical terminology for "writing unit" is "page", and many pages are grouped together into "blocks" (i.e. "erasing unit").– iBugCommented Sep 15, 2022 at 9:10
This is a good question. I suspect you are thinking of Flash as a physical device, which does need erasing before it can be written. Routers, loose flash chips, and embedded microcontrollers usually have this type.
SSDs, however, have a controller on them that makes the device look like a mechanical drive (for legacy reasons) to the computer. This means that the computer is able to arbitrarily rewrite sections of the drive without needing to issue erase commands itself*. This is slow, especially if the computer's write operation didn't change the entire erase block of the flash (thus requiring that the valid sections be moved to another region, which takes more time).
To solve this issue, TRIM was created. TRIM is a signal to the flash controller that some sections of memory no longer contain data (blank/deleted isn't the same as "unused"). The controller can then choose unused blocks to store your new files, since it won't need to move any data from them before erasing.
By turning off TRIM, you disable this optimization system (potentially bad for the lifespan of your drive and also making it slower) but you by no means prevent it from storing new data.
*There are additional details with how flash wear leveling and this "mechanical drive emulation" feature work, but they aren't really important here.