Comment by kasabali
2 years ago
You don't need to go through all that trouble to use most cheap DRAMless SSDs in pSLC mode. You can simply under-provision them by using only 25-33% capacity.
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).
How can I verify that things stay this way?
Partitioning off a small section of the drive feels very 160 GB SCSI "Let's only use the outer sectors".
Even keeping the drive always 75% empty would be enough, but partitioning off is the easiest way to make sure it's never exceed 25-33% full (assuming the drive behaves like that in the first place).
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.
> Partitioning off a small section of the drive feels very 160 GB SCSI "Let's only use the outer sectors".
In that it was very reliable at accomplishing the goal?
Short stroking bigger disks for higher IOPS and storage speed was a de-facto method in some HPC centers. Do this to a sufficiently large array and you can see unbelievable IOPS numbers for that generation of hardware.
That is what an ideal FTL would do if only a fraction of the LBAs are accessed, but as you say some manufacturers will customise the firmware to do otherwise, while this mod basically guarantees that the whole space is used as SLC.
Scroll down to the section called “SLC CACHING” towards the end of TFA. Your approach will work for only 45GB though the actual SLC cache is 120GB in size, because the process kicks in before the SLC is fully consumed (so it can page on and out of it).
If you don’t need 66% of the drive’s SLC capacity, the small partition approach is indeed easier and safer.
Oh, I've already did. You'll see that if you scroll up and read the last sentence in my comment above.
How do you make sure the empty space is trimmed? Can you trim a portion of a disk?
The literal answer is yes, an ATA TRIM, SCSI UNMAP, or NVMe Deallocate command can cover whatever range on a device you feel like issuing it for. (The device, in turn, can clear all, none, or part of it.) On Linux, blkdiscard accepts the -o, --offset and -l, --length options (in bytes) that map more or less exactly to that. Making a(n unformatted) partition for the empty space and then trimming it is a valid workaround as well.
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.
Create a partition that you'll never use and run blkdiscard [1] from util-linux on it.
[1]: https://man7.org/linux/man-pages/man8/blkdiscard.8.html / https://github.com/util-linux/util-linux/blob/master/sys-uti...
AFAIK Windows runs TRIM when you format a partition. So you can create a dummy partition and format it. Then you can either delete or simply not use it.
On Linux, blkdiscard can be used in the same manner (create a dummy partition and run blkdiscard on it ex. *blkdiscard /dev/sda2).
If one prefers working with LVM for their devices, that can be a similar wrench. Making/removing a logical volume can do the same
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.
Windows by default issues TRIMs basically instantly when deleting a file, and runs "Optimize disk" (which trims all free space) on a schedule by default as well.
You can go into Properties > Tools > Optimize, the same button that runs defrag on spinning drives runs TRIM on solid state devices.
What about external SSDs over USB? How do you trim those?
3 replies →
:mind-blown:
i knew about "preconditioning" for SSDs when it comes to benchmarking, etc. didn't realize this was the why.
thanks!
What happens if the remaining space is TRIMMED but routinely accessed? (for example by dd, read only)
If a logical block address is not mapped to any physical flash memory addresses, then the SSD can return zeros for a read request immediately, without touching the flash.
Does the mapping happen on first write? Is TRIM then a command that signals the SSD to unmap that block?
1 reply →
You read zeroes.
Not guaranteed by default for NVMe drives. There's an NVMe feature bit for "Read Zero After TRIM" which if set for a drive guarantees this behavior but many drives of interest (2024) do not set this.
2 replies →
ssd firmwares are a mistake. they saw how easy it is to sell crap, with non ecc (i.e. bogus ram) being sold as the default and ran (pun intended) with it.
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.
> giving you more data resilience in short term but wasting more write cycles because they're technically writing 1111111 instead of 1. every time.
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.
Technically they are writing (0,0,0,1) instead of (0.0625).