You received this message because you are subscribed to the Google Groups "Felton LUG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to felton-lug+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/felton-lug/1939958347.84241.1663113205326%40mail.yahoo.com.
Thanks, Larry! That did it -- I found a couple things but nothing that jumps out.I do see an old docker. container under /var/lib but that doesn't explain why Ihave this problem.
I the root partition on an SSD drive? I've seen odd problems on Windoze machines, where the user erased a very large file, but the TRIM function hadn't yet released erased blocks marked for reallocation. The symptom was that the SSD continued to act like it was out of available space until something triggered the SSD TRIM function, when it magically showed plenty of space available. My guess(tm) is that something similar can happen in Linux. The fix is to manually run:
sudo fstrim / -v
If this works, you should probably look into why the automatic TRIM function in Linux is not running or working. TRIM (discard) is run when booting the machine. I thought that fstrim was also run from cron, but apparently not. See:
systemctl status fstrim systemctl status fstrim.timer
I confess that I haven't seen an SSD with this problem on a Linux
machine, so this is all speculation on my part. However, I don't
think it hurts to run fstrim the next time you erase big files or
try to do useful work with an almost full SSD.
If you try the fstrim command on a conventional hard disk drive,
you'll get an error message something like "The discard operation
is not supported".
-- Jeff Liebermann je...@cruzio.com PO Box 272 http://www.LearnByDestroying.com Ben Lomond CA 95005-0272 Skype: JeffLiebermann AE6KS 831-336-2558
sudo fstrim / -v
That should be:
fstrim / -av
so that all the partitions (including swap) are trimmed.