<semi-SOLVED> I am new to SSD drives...need guidance

[rene]

I thought that meant that 1.8g was all that was trimmed and not free space left on the drive.

That is as mentioned above the basically same thing: fstrim just reports to the SSD which blocks are in fact free; it's the SSD itself that then erases those blocks, but while taking care to not bother for blocks that have not in fact been written to since the previous erase.

And yes, that's also to say you needn't be careful running an fstrim manually; a freed block will only ever be trimmed, i.e., written to, once anyway. The warning as posted by philotux above is in the context of especially crummy SSDs that trim an already trimmed block. I'm not in fact sure there are any, although I suppose some old ones from the time when TRIM support was new could. Anything remotely current and/or non-Chinese is fine...

[philotux]

And yes, that's also to say you needn't be careful running an fstrim manually; a freed block will only ever be trimmed, i.e., written to, once anyway. The warning as posted by philotux above is in the context of especially crummy SSDs that trim an already trimmed block. I'm not in fact sure there are any, although I suppose some old ones from the time when TRIM support was new could. Anything remotely current and/or non-Chinese is fine...

Great! Thanks for the clarification!

[DAMIEN1307]

"disks" shows what i already knew after the TRIM was performed, "256 GB — 215 GB free (16.1% full)" the SSD is 256GB total and after install i put 32 more GBs into it off my flash drive to test things out...my thinking is that indeed 1.8 GBs was trimmed since that would account for things that i would have deleted from new, fresh installation...(keep in mind this is a brand new install and did not expect much "cruft" to be there to begin with)...thanks to all here for advice and knowledge given as well, not only did i learn alot of what i did not know about SSDs but also got a more in-depth view into the inner workings of systemd which i was already fairly good at but now see that there are a few "chinks in the armour" as well...DAMIEN

[DAMIEN1307]

just ran manual TRIM one more time after giving system a heavy thorough testing last night and now have a decent number in trim to report...DAMIEN

Code: Select all

damien@damien ~ $ sudo fstrim -av
/: 200 GiB (214784745472 bytes) trimmed
damien@damien ~ $ 

[rene]

Note there's something deceptive going on here....

While I could swear this wasn't the case when I last checked, currently an fstrim -av immediately following another fstrim -av reports no to be trimmed space on the second run, giving the impression that the displayed number on the first run is space being actually and actively trimmed -- but just reboot between the two fstrim's to see the second run report the same figures as the first, even though clearly nothing's been written to in between.

This would seem to say there is a kernel-level (or more likely, device-level but as reported to the kernel) fstrim "cache" active. Don't currently have time to investigate deeply but will seemingly have to adjust my "reported fstrim space = free space" answer to specify " ... on the first run after boot".

Will investigate later. But, again, really...

[rene]

OK, it is in fact a kernel-level, better file-system level, fstrim "cache". Simply un- and remounting an (ext4) file system has the fstrim reported number go back to the free space number. I.e., nothing fundamentally wrong about what I said, including manual fstrim's not hurting anything, but I'll need to take note to more specifically add "for the first one during one boot, better, one mount" to any "fstrim reported space = free space" statements I care to make in the future.

What I think of that file system level "cache" / behaviour I shall for now not comment on...

[redlined]

interesting thing i just found out by removing it...once the fstrim timer was removed, i re-ran the original code that rene gave me,

Code: Select all

systemctl list-timers

and it came back more like what his looks like...when i ran it when fstrim was enabled for automatic action, the sections marked UNIT and ACTIVATES were completely missing...now when running that command after deactivating automatic fstrim it appears in the read-out...was that a systemd type error caused by the fstrim timer?...that is really confusing the heck out of me now...lol...i think i will just stick to manual control...DAMIEN

Great thread, thanks for initiating this convo Damien! So I caught up and ran the commands shared, and I found your output from systemctl list-timers was the exact same as I saw in terminal results running it 3 times (LM19.1 Cinnamon)

and it was not until I widened terminal from 80 to 100 that the command started showing the Unit column and at 112+ it finally started showing the Activates column. Very strange but I'd think it a bug since I'm expecting at least a wrap around for the two missing columns if width of terminal is not sufficient for the output

also noting that if before I hit "q" to quit the view and get prompt back that when adjusting terminal width it appears to have the list-timers command repeat output, followed by two dozen single tilde "~" this seems to happen with each width adjustment as the missing columns are exposed, it repeats the command output if I don't quit view. If I quit view and adjust then nothing is revealed as hidden, but running the command again gives the full output result (if width of terminal is 112+

I've also learned even though my schedule shows weekly fstrim, my grep results show it is happening daily so Ima need sort that out

[rene]

[ ... ] running the command again gives the full output result (if width of terminal is 112+

Thanks for commenting. And other than that..... sigh.

[redlined]

[ ... ] running the command again gives the full output result (if width of terminal is 112+

Thanks for commenting. And other than that..... sigh.

and I have no clue where to report such a bug seems cross-distro, so terminal app? shell/bash?

adding another reproducible effect to what I mentioned earlier, if command was run with terminal width 112+, or resized before Quit view to 112+, then Quit, then resizing back down does wrap the additional columns, as expected. Very weird that the columns are simply cut off completely when terminal is not initially wide enough for the output.

[rene]

A repeat of command output I'm not reproducing (in the Xfce Terminal) but otherwise the behaviour seems more or less as expected. systemctl list-timers displays in the pager as set in the environment variable SYSTEMD_PAGER or if not set, less if available. As per the information from man systemctl the default options with which less is called moreover incudes -S aka. --chop-long-lines. This is to say that truncation is the expected and explicitly intended behaviour; the lone tildes are moreover less' usual method of displaying lines past EOF. That lines are wrapped after quitting "the view", i.e., less, is also not surprising; at that point only the terminal emulator is involved.

That is, my "sigh" was less about this specific behaviour than about your comment clarifying that all the hullabaloo was just Damien muddling around in a stamp-sized terminal

[DAMIEN1307]

ahhhh, but it wasnt stamp sized when i did my copy and paste to report here Rene...i make it a habit to always full screen my terminal results before i copy and paste to the posts...what you saw was what i saw from a full screen sized terminal...i never muddle about in the small size terminal box...i always expand to full size screen...something more to sigh about and wonder if this is a systemd fault maybe on Peppermint 9 only?, a Peppermint fault in its implementation of systemd? and or both etc? its a tough call and i know that this one, is at the moment, a little beyond my scope of knowledge...and im not afraid to admit to it...lol...DAMIEN

[DAMIEN1307]

just another thought here...when letting TRIM do things automatically (it appears (at least on my peppermint system) to want to do so on an almost daily basis rather than a once a week cron job), if my thinking is correct, everything would be totally irretrievable for those who do not maintain a viable back up routine, whereas if your doing it only on a manual basis, then at least you know when you did it yourself last and if you did do something accidently, like wipe out all your precious photo files, at least you would have a decent chance of getting things back before the next manual TRIM of the SSD...would i be correct in this assumption?...DAMIEN

PS...as a side note, when i left for church today, i decided to leave my computer on and re-activated the automatic fstrim -av etc...when i came back and checked it with,

Code: Select all

journalctl | grep fstrim

,
it activated itself every hour...whereas that is really overly excessive, i have definitely decided to never leave it in automatic mode ever again...its manual only for me from now on...from now on its once a week at most and probably even better, at least for me, to no more than once a month since i rarely add anything to my daily driver without first testing things on three other test systems i have with various distros.

[philotux]

Damien, did you run the command given by smurphos above to check up on the frequency by which fstrim has run on your system?

Code: Select all

journalctl | grep fstrim

Or see if there is any log file in /var/log some fstrim.log or something.

[DAMIEN1307]

we overlapped again...lol...read my addendum to last post...it ran its self 5 times in 5 hours...DAMIEN

[HaveaMint]

I run it in cron-daily

Code: Select all

#!/bin/sh
LOG=/home/mark/Documents/trim.log
echo "*** $(date -R) ***" >> $LOG
fstrim -v / >> $LOG
fstrim -v /home >> $LOG

[philotux]

we overlapped again...lol...

we tend to do that, don't we?
Alright, now I see. It's quite odd since it say in one your posts above OnCalendar=weekly :

Code: Select all

damien@damien ~ $ systemctl cat fstrim.timer
# /lib/systemd/system/fstrim.timer
[Unit]
Description=Discard unused blocks once a week
Documentation=man:fstrim

[Timer]
OnCalendar=weekly
AccuracySec=1h
Persistent=true

[Install]
WantedBy=timers.target

[DAMIEN1307]

yep...lol...i noticed that also on that particular results to that command and yet there it was when i came home today, 5 times in 5 hours it ran itself, so i think it is best that i disabled the automatic which pleases to no end the control freak within me...i never did trust automation that much anyways...if i did, i would probably still be using Microcrap products...NOT happening...lol...lol...its on manual from now on and wiped out all the files for journald for now with the following 2 commands,

Code: Select all

journalctl --rotate

Code: Select all

 sudo journalctl --vacuum-time=1seconds

for a clean slate again on a day old clean slate newly installed system...DAMIEN

[DAMIEN1307]

well folks...this has been a voyage of discovery for me with something that is new in my little realm. i hope that others can benefit from my little sojourn here and will actually check their own SSDs just to see if anything like the automatic TRIM could also be running excessively which can result in a premature SSD failure eventually which is exactly why i started this thread was to learn more about SSDs and at least in my own case have discovered a potential flaw, at least in my case whether it be the fault of the particular SSD unit or how its automatic TRIM command is implemented with systemd and or the OS i am using or a combination of all three put together...in my case, manual is the only way to go, in anyone elses case, each needs to decide on their own depending on what they find that their SSD and system are doing, not doing, or overdoing. i hope this has been of help to others here...thank you to all who have contributed to this post...DAMIEN

PS...i never new it was possible to boot-up a computer in 3.1 to 3.5 seconds and watch it all happen in a literal flash, (i never thought i would ever improve over my WD 500 gb HDD boot-up time of 13 seconds),...when i see this, all i can say is WOW im impressed with SSD...its also using an intel i5 quad 4 CPU and 8 gigs of ram (corsair vengeance) and a 550 watt power supply with an ASUS mobo, I hand built this one in march of 2015.

[redlined]

As per the information from man systemctl the default options with which less is called moreover incudes -S aka. --chop-long-lines. This is to say that truncation is the expected and explicitly intended behaviour; the lone tildes are moreover less' usual method of displaying lines past EOF. That lines are wrapped after quitting "the view", i.e., less, is also not surprising; at that point only the terminal emulator is involved.

Thanks for sorting that rene, very good, all is well and as expected! (I just need to get better at what to expect, of course man --help command(s) can and do help in that regard

All,

Yesterday I ran systemctl cat fstrim.timer and know what I was seeing yesterday when I ran commands this thread, was the same output Damien was reporting, hence my surprise I saw "OnCalendar=weekly" then journalctl | grep fstrim showed it was running daily adding to my confusion.

Just now I reran systemctl cat fstrim.timer and there is more reported, so now it's just weird, but at least I know where to see the offending 'daily' override.

Code: Select all

~$ systemctl cat fstrim.timer
# /lib/systemd/system/fstrim.timer
[Unit]
Description=Discard unused blocks once a week
Documentation=man:fstrim

[Timer]
OnCalendar=weekly
AccuracySec=1h
Persistent=true

[Install]
WantedBy=timers.target

# /etc/systemd/system/fstrim.timer.d/override.conf
[Timer]
OnCalendar=
OnCalendar=daily

rename override.conf (to .bak using sudo mv command) or edit the contents (used xed admin:/// for that) throws up error when again run systemctl cat fstrim.timer advising to reload systemctl daemon, sudo systemctl daemon-reload then ran cat fstrim.timers and the override.conf is rebuilt/repaired (and my admin:// edit - commented out daily line was apparently added back) so I need to sort how to stop that override, any ideas?

edit to add: reading up in man fstrim && systemctl now

[rene]

I believe you may have at one point bumped into viewtopic.php?f=49&t=282032&hilit=override#p1555681 or similar and decided to experiment. Simply deleting the /etc/systemd/system/fstrim.timer directory or more specifically its contained override.conf should get properly rid of it.