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" <[email protected]> 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 [email protected] > Unsubscribe from this mailing list > https://gtalug.org/mailman/listinfo/talk --- Post to this mailing list [email protected] Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
