Hi, Thank you for your war story, for me it was very useful as it relates to SSD :) On Fri, 19 Mar 2021 11:24:11 -0400 (EDT) "D. Hugh Redelmeier via talk" <talk@gtalug.org> wrote:
[One reason for this message is to test if the mailing list is working. I haven't seen a new message in a 10 days.]
dmseg command =============
The dmesg command shows you the kernel log. It takes the log from the kernel itself. It is stored in a circular RAM buffer, so you can still read it if the normal logging system isn't working. This buffer is a fixed size so older messages can get pushed out by newer ones if there is enough logging going on.
You can get more info on Fedora by journalctl -b but it isn't limited to kernel messages. It does colour-code messages based on severity, so that's a nice plus. Since this log typically goes to disk, it tends to be complete. Oh: the -b flag means: start from the most recent boot -- logs can go back months and years.
As an old timer, my first instinct is to use dmesg.
looking at kernel messages ==========================
dmesg | less -i
dmesg pours out a lot of lines. less is a good way of navigating this log. The -i makes searches within less case-insensitive.
The Linux kernel is meant to log problems and move on. This means that there can be problems that you don't even know about because all looks well. I think it pays to once in a while look for problems reported in the log.
A lot of messages will be inscrutable. If they intrigue you, investigate them.
Here's one I noticed recently on one of my systems. It's been there for the whole life of the system, but I never noticed.
[ 2.545003] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 2.545482] ata1.00: supports DRM functions and may not be fully accessible [ 2.545554] ata1.00: READ LOG DMA EXT failed, trying unqueued [ 2.548363] ata1.00: disabling queued TRIM support [ 2.548370] ata1.00: ATA-9: Crucial_CT240M500SSD1, MU05, max UDMA/133 [ 2.548376] ata1.00: 468862128 sectors, multi 16: LBA48 NCQ (depth 31/32), AA [ 2.551973] ata1.00: supports DRM functions and may not be fully accessible [ 2.554812] ata1.00: disabling queued TRIM support [ 2.558006] ata1.00: configured for UDMA/133
Look at "disabling queued TRIM support". What's that about?
- TRIM is a useful feature in SSDs. It allows the OS to advise the SSD that chunks of the filesystem are no longer needed (eg. deleted files). This helps the SSD's wear-levelling firmware's garbage collector. It should help speed up the SSD and add to its lifetime.
- Even without queued TRIM, TRIM can still be accomplished. Queued TRIM is some higher-performance variant (I haven't investigate).
But what's up with this message? Googling got me to <https://bugzilla.kernel.org/show_bug.cgi?id=71371> Very useful.
- apparently my SSD (a Crucial M500) had buggy firmware, leading to corruption in some cases. Including queue TRIM
- Crucial released new firmware (in 2015) <https://www.crucial.com/support/ssd-support/m500-support>
- my SSD has this firmware (MU05), as reported in the dmesg output
- even after the update, M500's screw up queued TRIM
- the Linux kernel embeds all this wisdom and it blacklists queued TRIM on my box
I spent an hour investigating this. There was no effect, except that I learned a few things. Linux just does the right thing.
I do recommend also looking at journalctl output because it highlights things that it thinks are of particular interest. --- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk