On Linux, blkdiscard can be used in the same manner (create a dummy partition and run blkdiscard on it ex. *blkdiscard /dev/sda2).
It depends on 'issue_discards' being set in the config
This has drifted over time. I haven't quite rationalized why. Hoping someone can remind me if nothing else, away from a real computer for a bit.
Apparently macOS doesn't expose the ability for userspace to manually issue trim commands to block devices (or at least doesn't ship a suitable tool to do so), so the best available workaround is to tell the filesystem layer that it should do automatic trimming even on external drives.
[1]: https://man7.org/linux/man-pages/man8/blkdiscard.8.html / https://github.com/util-linux/util-linux/blob/master/sys-uti...
But you’re most probably doing this on a device with nothing valuable on it, so you should be able to just trim the whole thing and then allocate and format whatever piece of it that you are planning to use.
i knew about "preconditioning" for SSDs when it comes to benchmarking, etc. didn't realize this was the why.
thanks!
so if under provisioned now they work as pSLC, giving you more data resilience in short term but wasting more write cycles because they're technically writing 1111111 instead of 1. every time. if you fill them up then they have less data resilience.
and the best part, there's no way you can control any of it based on your needs.
No, that's not how it works. SLC caches are used primarily for performance reasons, and they're faster precisely because they aren't doing the equivalent of writing four ones (and especially not seven!?) to a QLC cell.
Partitioning off a small section of the drive feels very 160 GB SCSI "Let's only use the outer sectors".
To verify the drive uses the all of the drive as a cache, you can run full drive sequential write test (like the one in HD Tune Pro) and analyze the speed graph. If, say, a 480GB drive writes at full speed for the first 120GB, and then the write speed drops for the remaining 360GB, this means the drive is suitable for this kind of use.
I think controllers might've been doing some GC jobs to always keep some amount of cells ready for pSLC use, but it should be a few GBs at most and shouldn't affect the use case depicted here.
In that it was very reliable at accomplishing the goal?
If you don’t need 66% of the drive’s SLC capacity, the small partition approach is indeed easier and safer.
Most low end DRAMless controllers run in full disk caching mode. In other words, they first write *everything* in pSLC mode until all cells are written, only after there are no cells left they go back and rewrite/group some cells as TLC/QLC to free up some space. And they do it only when necessary, they don't go and do that in background to free up more space.
So, if you simply create a partition 1/3 (for TLC) or 1/4 (for QLC) the size of the disk, make sure the remaining empty space is TRIMMED and never used, it'll be always writing in pSLC mode.
You can verify the SSD you're interested in is running in this mode by searching for a "HD Tune" full drive write benchmark results for it. If The write speed is fast for the first 1/3-1/4 of the drive, then it dips to abysmal speeds for the rest, you can be sure the drive is using the full drive caching mode. As I said, most of these low-end DRAMless Silicon Motion/Phison/Maxion controllers are, but of course the manufacturer might've modified the firmware to use a smaller sized cache (like Crucial did for the test subject BX500).