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?
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 queuing
TRIMcommands (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.
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.
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.
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.
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.