IAmLiterallyAB
Joined 8 years ago
Joined 8 years ago
I might give it a try when I have a chance, I'll let you know if anything comes of it.
> This includes things like asm volatile("" : : : "memory"), which is an old-school way of saying atomic_signal_fence(memory_order_seq_cst).
Not quite. AIUI, the first is just a barrier for the compiler, while the second is also a CPU memory barrier. Godbolt seems to confirm that.
Better than outlook though. What a nightmare.
No one is stopping you from using the telnet client. And really you should just use netcat
The block device you see is an abstraction provided by the SSD controller. In reality, the flash capacity is larger. Pages are swapped out for wear leveling. If a block goes bad, it'll be taken out of commission, and your data may hide in there.
All of this happens on the SSD controller. The kernel doesn't know. You have no way to directly erase or modify specific blocks.
*Okay, there are raw NAND flash chips without controllers, but that is not you're working with when you have a SSD or flash drive. If you do have a raw flash chip, you can more directly control flash contents.
Which in theory should free all of the blocks on the flash.
Really hard to find good documentation on this stuff. Doesn't help that 95% of internet articles just say "overwrite with zeroes" which is useless advice