Trying to reduce dmesg btrfs spamming to reduce SSD wear - and now what?

[oshunluvr]

So I got tired of a set of dmesg entries filling up my logs, specifically these two:

[Mon Jun 29 02:16:11 2026] ata11.00: Enabling discard_zeroes_data
[Mon Jun 29 02:16:11 2026] ata12.00: Enabling discard_zeroes_data

and a couple more related to them. This is a 24/7 server so logging goes on continually so I thought I might get a few mores years out of the root storage device if I log less.

Some internet sleuthing and my own observations led me to this conclusion: The drives attached to ata11+12 are older (as in a decade) SSD's and both were btrfs formatted without a partition table. This was the source of the message - letting me know that the drives were able to support trim (discard) correctly. The newer SSDs don't do this nor do the HDs. So I reformatted both SSDs with a partition table and a single partition and those messages are gone.

UFW logs a lot but it's set to "low" and I want some logging from it so I guess I live with those (15-60 a day). However, one of my Roku TVs is causing these messages! Hopeully this will fix this one:

sudo ufw allow from 192.168.1.15

and I set it's IP the fixed address.

Finally, I'm seeing - about every 30 minutes - this:

sdb: sdb1 sdb2 sdb3 sdb4

Sort of an announcement of the partitions on this hard drive It's not even mounted. Still working on that one...

[oshunluvr]

Internet says the sdb message relates to device disconnect/reconnect.

/dev/sdb is fine according to SMART. It's a 6TB WD "Red" server drive and it is the oldest drive on the server. No issues that show up.

It was not mounted at the time of the log message and is not mounted except at 5:30am for backup use. It's mounted, backup made, then unmounted automatically via a cron job.