| 1 |
On Monday, 13 April 2020 06:32:37 BST tuxic@××××××.de wrote: |
| 2 |
> Hi, |
| 3 |
> |
| 4 |
> From the list I already have learned, that most of my concerns regarding |
| 5 |
> the lifetime and maintainance to prolong it are without a |
| 6 |
> reason. |
| 7 |
|
| 8 |
Probably your concerns about SSD longevity are without a reason, but keep up |
| 9 |
to date backups just in case. ;-) |
| 10 |
|
| 11 |
|
| 12 |
> Nonetheless I am interested in the technique as such. |
| 13 |
> |
| 14 |
> My SSD (NVme/M2) is ext4 formatted and I found articles on the |
| 15 |
> internet, that it is neither a good idea to activate the "discard" |
| 16 |
> option at mount time nor to do a fstrim either at each file deletion |
| 17 |
> no triggered by a cron job. |
| 18 |
|
| 19 |
Beside what the interwebs say about fstrim, the man page provides good advice. |
| 20 |
They recommend running a cron job once a week, for most desktop and server |
| 21 |
implementations. |
| 22 |
|
| 23 |
|
| 24 |
> Since there seems to be a "not so good point in time", when to do a |
| 25 |
> fstrim, I think there must also be a point in time, when it is quite |
| 26 |
> right to fstrim the mu SSD. |
| 27 |
> |
| 28 |
> fstrim clears blocks, which currently are not in use and which |
| 29 |
> contents is != 0. |
| 30 |
> |
| 31 |
> The more unused blocks there are, which has a contents != 0, the |
| 32 |
> lesser the count of blocks is, which the wear leveling algorithm can |
| 33 |
> use for its purpose. |
| 34 |
|
| 35 |
The wear levelling mechanism is using the HPA as far as I know, although you |
| 36 |
can always overprovision it.[1] |
| 37 |
|
| 38 |
> That leads to the conclusion: to fstrim as often as possible, to keep the |
| 39 |
> count of empty blocks as high as possible. |
| 40 |
|
| 41 |
Not really. Why would you need the count of empty blocks as high as possible, |
| 42 |
unless you are about to right some mammoth file and *need* to use up every |
| 43 |
available space possible on this disk/partition? |
| 44 |
|
| 45 |
|
| 46 |
> BUT: Clearing blocks is an action, which includes writes to the cells of |
| 47 |
> the SSD. |
| 48 |
> |
| 49 |
> Which is not that nice. |
| 50 |
|
| 51 |
It's OK, as long as you are not over-writing cells which do not need to be |
| 52 |
overwritten. Cells with deleted data will be overwritten as some point. |
| 53 |
|
| 54 |
|
| 55 |
> Then, do a fstrim just in the moment, when there is no useable block |
| 56 |
> left. |
| 57 |
|
| 58 |
Why leave it at the last moment and incur a performance penalty while waiting |
| 59 |
for fstrim to complete? |
| 60 |
|
| 61 |
|
| 62 |
> Then the wear-leveling algorithm is already at its limits. |
| 63 |
> |
| 64 |
> Which is not that nice either. |
| 65 |
> |
| 66 |
> The truth - as so often - is somewhere in between. |
| 67 |
> |
| 68 |
> Is it possible to get an information from the SSD, how many blocks are |
| 69 |
> in the state of "has contents" and "is unused" and how many blocks are |
| 70 |
> in the state of "has *no* contents" and "is unused"? |
| 71 |
> |
| 72 |
> Assuming this information is available: Is it possible to find the |
| 73 |
> sweat spot, when to fstrim SSD? |
| 74 |
|
| 75 |
I humbly suggest you may be over-thinking something a cron job running fstrim |
| 76 |
once a week, or once a month, or twice a month would take care of without you |
| 77 |
knowing or worrying about. |
| 78 |
|
| 79 |
Nevertheless, if the usage of your disk/partitions is variable and one week |
| 80 |
you may fill it up with deleted data, while for the rest of the month you |
| 81 |
won't even touch it, there's SSDcronTRIM, a script I've been using for a |
| 82 |
while.[2] |
| 83 |
|
| 84 |
|
| 85 |
[1] https://www.thomas-krenn.com/en/wiki/SSD_Over-provisioning_using_hdparm |
| 86 |
[2] https://github.com/chmatse/SSDcronTRIM |
Archives