I would suspect the constant writing (trickle writing, small writes) prevents the firmware from entering into garbage collection mode and erase/recover blocks of flash memory marked for erase
Flash memory is arranged in blocks (ex 24/32/64 MB or higher blocks of flash, which are then arranged in pages of 512 bytes or 4096 bytes or other sizes) - the controller can write to an empty page, but can't overwrite that page - in order to make the page available for writing the whole block (64 MB or whatever size it is) has to be erased (and that erase process wears out the flash memory).
So each time something has to be overwritten, the controller just finds an empty page somewhere in other parts of the flash drive, copies the old page with the changed bytes to a new page , marks the old page for erase, and updates a lookup table that says contents previously on block x , page y is now in block m, page n .... (off topic that lookup table is usually cached in ram at startup and makes dram based ssds a bit faster, dram isn't used to cache writes)
When there's a threshold of erased pages out of a block reached, for example 90% of pages from a 64 MB block, the controller copies the remaining 10% of pages in random places and then erases the block and makes it available to the system.
If the controller doesn't detect some idle time, it's possible it never erases blocks so the more time it takes the harder it is for the controller to find empty pages to put content into, and it may not have enough empty blocks to convert from TLC to pseudo-SLC to faster write speeds.
One potential solution would be to run the TRIM command (Windows defrag tool will do it on SSDs instead of defragmenting, TRIM will force the drive to do cleanup)
Most drives use pseudo-SLC to cache writes - what they do is take one of those blocks of 24/32/64 MB of flash memory where each cell holds 2 bits for MLC, 3 bits for TLC and 4 bits for QLC, and convert the block to SLC mode storing just one bit in each cell - so for example 64 MB of QLC becomes 16 MB of fast SLC cache, 64 MB of TLC becomes around 20 MB of SLC cache etc etc.
You write stuff, controller puts it in SLC cache and afterwards at idle time, it will slowly move the data to TLC memory areas.
Blocks in pseudo-SLC mode wear out slower ... maybe 10k erases QLC is rated for 200-600 erases, TLC goes from around 1000 to 4000 erases, MLC goes up to around 10-15k erases, SLC goes from 10k to maybe 30-50k erases, some small slc chips can do even 100k erases.
-
OP , if your backups are a few GB or less, I would suggest seeing if you can spin up a ram disk before your backup - for example on Windows I use ImDisk toolkit and can create ram drives with or without physical backup (disk image). Without a disk image, I can set up a 10 GB ram drive (because I have 16 GB of ram) in seconds and quick format it to NTFS and you could compress the data to the RAM drive, then simply copy the archive to the SSD in a burst.
You may also take advantage of this to sort your file types and then pack together your files in a TAR archive (7zip can create TAR archives) and you could run a DIFF between previous backups and current backup. I like XDelta (open source tool) but there's other binary diff tools.
Keep each day's archive for 30 days, after that you could keep only 1st day of the week or month and then for the next days keep the diffs only (so if you want friday's backup, generate from diff between monday and friday). 7z in store mode may also work, but 7z format may shift some bytes around that could make it less efficient to do binary diffs. TAR is simpler, 512 byte blocks, if your files are sorted in same order then a binary diff would easily store only the differences.
Home
Help
Search
Login
Register
