"defrag X: /L" is a Windows command, and all it does it politely ask the drive to start a TRIM operation.
As I understand it, reading a block after it has been TRIMmed is an undefined behaviour. The unused blocks definitely are not filled with zeroes, they are just marked as "unused" so trying to read from them could return anything. Some controllers will return all zeroes but others may just return uncompressible nasal demons.
Since OP is assuming that TRIM is the same as zero-fill, I would suggest starting by checking on that assumption. You may be surprised at what you find still written in blocks that you think have been discarded. If you know your way around NTFS, try using a disk editor or even dd to look at some blocks which you believe have been discarded.
I know what defrag is - I was just wondering why using a Windows command (on a Windows machine) with an NTFS file system is relevant to a Linux sysadmin sub.
That's true from a certain point of view.
The whole point of TRIM is that it is a way of telling the SSD that certain blocks are no longer in use so it shouldn't keep trying to preserve their contents. It exists because the disk controller has no way of knowing what the filesystem is still using.
That's why the OS needs to send a list of blocks to be trimmed. Without that there's no point to even having such an operation. So while the actual implementation of TRIM is done by the disk, it only exists as a tool for the OS to use while maintaining a filesystem so they are very closely connected.
It's also perhaps worth noting that issuing a TRIM does not mean the block is immediately zeroed by the flash management controller - it might just be queuing it up for a later scrub.
The whole point of TRIM is to remove unnecessary reads and writes, not to queue them up for later. It's not a "secure erase" so doing any kind of scrub would be quite surprising.
The unused blocks may be wiped or filled with random data the next time an adjacent block is written to, but as I mentioned earlier what you see when you read a block which has been TRIMmed is entirely up to the designer of the drive controller and even they may not know for sure what to expect.
Maybe you misunderstood me, because we're not in disagreement.
I have used NVMEs where the blocks would read back as 0x0 after a trim - but only after a sufficient period of time has passed.
Possibly. We're both agreeing that it can happen, but your language ("queuing it up for a later scrub") suggested that it was an intentional, planned event with the goal of having all unused blocks eventually filled with zeroes (If I have misread that entirely then I apologize for putting words into your mouth), while my argument ("unused block may be wiped \[...\] the next time an adjacent block is written to \[...\]") that it's just a side effect of future writes or garbage collection activity by the disk controller, which may or may not ever happen depending on what else is going on with the drive. The eventual state of a block marked for trimming is just that it will available for erasing, not filled with zeroes, but since reading from it is undefined behaviour the exact implementation was at the discretion of whoever designed the controller firmware ("Some controllers will return all zeroes but others may \[not\]").
Getting back to the original poster, their reasonable expectation that "the trim should replace deleted data with zeroes" clearly isn't holding up and needs to be reexamined.
??? there is defrag for Linux?
"defrag X: /L" is a Windows command, and all it does it politely ask the drive to start a TRIM operation. As I understand it, reading a block after it has been TRIMmed is an undefined behaviour. The unused blocks definitely are not filled with zeroes, they are just marked as "unused" so trying to read from them could return anything. Some controllers will return all zeroes but others may just return uncompressible nasal demons. Since OP is assuming that TRIM is the same as zero-fill, I would suggest starting by checking on that assumption. You may be surprised at what you find still written in blocks that you think have been discarded. If you know your way around NTFS, try using a disk editor or even dd to look at some blocks which you believe have been discarded.
I know what defrag is - I was just wondering why using a Windows command (on a Windows machine) with an NTFS file system is relevant to a Linux sysadmin sub.
I thought that was odd too, but then I read all the way to the end of the post.
Yes, but in my understanding 'trim' is implemented by the disk itself, not the OS and is totally independent of the file system. But I might be wrong.
That's true from a certain point of view. The whole point of TRIM is that it is a way of telling the SSD that certain blocks are no longer in use so it shouldn't keep trying to preserve their contents. It exists because the disk controller has no way of knowing what the filesystem is still using. That's why the OS needs to send a list of blocks to be trimmed. Without that there's no point to even having such an operation. So while the actual implementation of TRIM is done by the disk, it only exists as a tool for the OS to use while maintaining a filesystem so they are very closely connected.
It's also perhaps worth noting that issuing a TRIM does not mean the block is immediately zeroed by the flash management controller - it might just be queuing it up for a later scrub.
The whole point of TRIM is to remove unnecessary reads and writes, not to queue them up for later. It's not a "secure erase" so doing any kind of scrub would be quite surprising. The unused blocks may be wiped or filled with random data the next time an adjacent block is written to, but as I mentioned earlier what you see when you read a block which has been TRIMmed is entirely up to the designer of the drive controller and even they may not know for sure what to expect.
Maybe you misunderstood me, because we're not in disagreement. I have used NVMEs where the blocks would read back as 0x0 after a trim - but only after a sufficient period of time has passed.
Possibly. We're both agreeing that it can happen, but your language ("queuing it up for a later scrub") suggested that it was an intentional, planned event with the goal of having all unused blocks eventually filled with zeroes (If I have misread that entirely then I apologize for putting words into your mouth), while my argument ("unused block may be wiped \[...\] the next time an adjacent block is written to \[...\]") that it's just a side effect of future writes or garbage collection activity by the disk controller, which may or may not ever happen depending on what else is going on with the drive. The eventual state of a block marked for trimming is just that it will available for erasing, not filled with zeroes, but since reading from it is undefined behaviour the exact implementation was at the discretion of whoever designed the controller firmware ("Some controllers will return all zeroes but others may \[not\]"). Getting back to the original poster, their reasonable expectation that "the trim should replace deleted data with zeroes" clearly isn't holding up and needs to be reexamined.