ToxicExMachina wrote:

You don't need to run TRIM command at all if you mount filesystem with 'discard' option.

The discard option slows down the drive because TRIM is applied for all I/O operations.

Any write operation is slowing down an SSD due to physical limitations. In practice the 'discard' option is just convenient thing with insignificant overhead.

You don't need to run TRIM command at all if you mount filesystem with 'discard' option.

The discard option slows down the drive because TRIM is applied for all I/O operations.

Yes, but thenI'd be running trim every time I booted the rig, which could be up to three or four times a day.

I'm looking to analyse the /var/log/trim files in a month or so to see what went on and then decide on weekly, monthly or something else.

There's a chap that wrote a daemon for running trim here:

https://github.com/dobek/fstrimDaemon

He argues that it would seem to be "more reliable to execute fstrim based on up time then cron table.".

Thanks for your input.

Cheers,

A.

Done.
Works a treat.  =-)

#!/bin/sh
# trim all mounted file systems which support it
# added 20200315
#
LOG=/var/log/trim.log
echo "*** $(date -R) ***" >> $LOG
fstrim --all --verbose >> $LOG

groucho@devuan:~$ cat /var/log/trim.log
*** Sun, 15 Mar 2020 17:51:27 -0300 ***
/var/log: 0 B (0 bytes) trimmed
/home: 112 MiB (117415936 bytes) trimmed
/: 483.9 MiB (507346944 bytes) trimmed
groucho@devuan:~$ 

Just changed the name of the cron job so that it would not be the same as the executable.
Thanks for your input.

Cheers,

A.

Right. (A bit late in life but I have vowed to try to stop using OK)

I see.

Hmm ...
I'll start looking again to see if I can find out just where it comes from.

I was just about to do that when I found trimmed_log.txt.

--- solved ---

From its content and name, it seemed (to me) that it could have been produced by fstrim.
But it turns out that it is not.   =-)

A search on the web brought up just three hits, one of them from a thread I (!) started here at Dev1.
So it turned out that it was right in front of me/us.

See here:
https://dev1galaxy.org/viewtopic.php?pid=20206#p20206

And here:
https://dev1galaxy.org/viewtopic.php?pid=20211#p20211

It was generated when I was trying to figure out how many pages my M2020W cartdrige had actually printed before running out.
Which I still have to figure out how to awk properly.

Thanks a lot for your input.

Cheers,

A.

But I am still far from finding out where (in my Devuan ascii) fstrim is started and under what circumstances.

I don't think it's started automatically at all. The Debian util-linux package supplies systemd timer & service unit files to allow it to be configured to run automatically every week but the Devuan package doesn't include those files or any cron jobs to replace them.

That trimmed_log.txt file in your home directory must be for something else.

To get fstrim running every week create a cron job for it, as I have shown.

Thanks ...
Already had it.

Indeed ...

I use locate and grep every day.
I have used which, whereis, ps and htop at some time or another as part of a script I copied from the web.

The rest I have not come across, at least that I remember.
Thanks for the pointer.

But I am still far from finding out where (in my Devuan ascii) fstrim is started and under what circumstances.

One thing I found and think it is important:

https://unix.stackexchange.com/question … -do-fstrim

I would have expected to find the cron job for fstrim in /etc/cron.daily, /etc/cron.weekly or /etc/cron.monthly but it is not there. 

I would like to edit the configuration file so that it logs in /var/log/fstrim.log with the verbose option so I know what it is doing or even disable it.
Instead just basic data in trimmed_log.txt in my /home directory.

Any idea as to where it is in Devuan ascii?

Thanks for your input.

Cheers,

A.

Tools to investigate (use the link, for instance) are (in no particular order):
which, strace, ps, whereis, grep/egrep/pgrep, lsof, locate/slocate and htop

I posted and went to make myself an espresso which made my head work a bit better.

So:

groucho@devuan:~$ locate trim
/home/groucho/trimmed_log.txt
/sbin/fstrim
/usr/share/bash-completion/completions/fstrim
/usr/share/man/man3/malloc_trim.3.gz
/usr/share/man/man8/fstrim.8.gz
/usr/share/tools/trim26lst
groucho@devuan:~$ 

Seems that the fstrim util is in/part of the Devuan ascii distribution.
And from the locate printout, it also seems that it has been run before.

groucho@devuan:~$ cat /home/groucho/trimmed_log.txt
[30/Nov/2018:10:44:10-0300] 1
[08/Dec/2018:19:12:32-0300] 1
--- snip ---
[17/Feb/2020:13:44:14-0300] 1
groucho@devuan:~$ 

The trimmed_log.txt (which for some strange reason is not in /var/log) only gives date, time and what would be the trim (?).

But ...

I only installed the SSD yesterday, no SSDs before that, so fstrim was working on some other drive.
I speculate that it was on the SAS drive replaced with the Kingston SSD ie: boot drive. (?)

Q:
1. How is fstrim set up and started? 
2. Will it keep working now albeit on the SSD?

Some dates in /home/groucho/trimmed_log.txt are far apart and there are up to 30 entries with the same date (with trims as high as 24 so it does not seem to be a cron job.

So if it is not a cron job, what triggers it to run and how can it be modified?

Thanks in advance,

A.

Can't get just the fstrim-mx by itself?

Well you could download the .deb package then unpack it and copy the script to /etc/cron.weekly but it's more or less the same as the one I've posted (it uses bash instead of /bin/sh for some reason though, which is slower, potentially more buggy and slightly more memory-intensive).

Don't add the # /etc/cron.weekly/fstrim line if you copy my script though, that's just my lazy way of indicating the filename & location.

It seems that it is part of a 'goodies' package (how I abhor this goodies crap)

http://mxrepo.com/MX19packages.html

Can't get just the fstrim-mx by itself?

# /etc/cron.weekly/fstrim
#!/bin/sh
LOG=/var/log/trim.log
echo "*** $(date -R) ***" >> $LOG
fstrim --all --verbose >> $LOG

OK.

Q: how come it is not in (any realease, actually) the devuan repository?

Good to know.

Cheers,

A.

Are there any system tweaks needed to keep the SSD in proper shape?

Use a weekly cron job to run fstrim on the drive to maintain performance, MX Linux has one you can "steal":

# /etc/cron.weekly/fstrim
#!/bin/sh
LOG=/var/log/trim.log
echo "*** $(date -R) ***" >> $LOG
fstrim --all --verbose >> $LOG

But don't bother following any obsolete advice to minimise writes, I actually have one of those Kingston drives and the longevity is great. See also https://techreport.com/review/27909/the … -all-dead/

I don't think it is the case here.

Yes, I had read something about that.

I'll see if I can find if there is a utility that can log swap activity (I think I saw one once ...) over a set amount of time, say 30/60/120 days and evaluate the results.
I have enough relatively fast SAS 3.0Gb/sec rust so I could eventually set up an 8.0Gb swap partition on one of them.

Thanks for your input.

Cheers,

A.