On Monday, 13 April 2020 06:32:37 BST tu...@posteo.de wrote: > Hi, > > From the list I already have learned, that most of my concerns regarding > the lifetime and maintainance to prolong it are without a > reason.
Probably your concerns about SSD longevity are without a reason, but keep up to date backups just in case. ;-) > Nonetheless I am interested in the technique as such. > > My SSD (NVme/M2) is ext4 formatted and I found articles on the > internet, that it is neither a good idea to activate the "discard" > option at mount time nor to do a fstrim either at each file deletion > no triggered by a cron job. Beside what the interwebs say about fstrim, the man page provides good advice. They recommend running a cron job once a week, for most desktop and server implementations. > Since there seems to be a "not so good point in time", when to do a > fstrim, I think there must also be a point in time, when it is quite > right to fstrim the mu SSD. > > fstrim clears blocks, which currently are not in use and which > contents is != 0. > > The more unused blocks there are, which has a contents != 0, the > lesser the count of blocks is, which the wear leveling algorithm can > use for its purpose. The wear levelling mechanism is using the HPA as far as I know, although you can always overprovision it.[1] > That leads to the conclusion: to fstrim as often as possible, to keep the > count of empty blocks as high as possible. Not really. Why would you need the count of empty blocks as high as possible, unless you are about to right some mammoth file and *need* to use up every available space possible on this disk/partition? > BUT: Clearing blocks is an action, which includes writes to the cells of > the SSD. > > Which is not that nice. It's OK, as long as you are not over-writing cells which do not need to be overwritten. Cells with deleted data will be overwritten as some point. > Then, do a fstrim just in the moment, when there is no useable block > left. Why leave it at the last moment and incur a performance penalty while waiting for fstrim to complete? > Then the wear-leveling algorithm is already at its limits. > > Which is not that nice either. > > The truth - as so often - is somewhere in between. > > Is it possible to get an information from the SSD, how many blocks are > in the state of "has contents" and "is unused" and how many blocks are > in the state of "has *no* contents" and "is unused"? > > Assuming this information is available: Is it possible to find the > sweat spot, when to fstrim SSD? I humbly suggest you may be over-thinking something a cron job running fstrim once a week, or once a month, or twice a month would take care of without you knowing or worrying about. Nevertheless, if the usage of your disk/partitions is variable and one week you may fill it up with deleted data, while for the rest of the month you won't even touch it, there's SSDcronTRIM, a script I've been using for a while.[2] [1] https://www.thomas-krenn.com/en/wiki/SSD_Over-provisioning_using_hdparm [2] https://github.com/chmatse/SSDcronTRIM
signature.asc
Description: This is a digitally signed message part.
