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.

[oshunluvr]

I also cannot get UFW to stop reporting "blocks" on my local network. I have added every rule I can think of to allow all traffic from my local IP range, but about every 15 minutes it still reports :

[UFW BLOCK] IN=eno1 OUT= MAC=fc:aa:14:91:fd:c1:cc:a1:2b:79:d0:f4:08:00 SRC=192.168.1.15 DST=192.168.1.250 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=11428 DF PROTO=TCP SPT=8060 DPT=57140 WINDOW=0 RES=0x00 RST URGP=0

The weird thing is all the IPs that are in the messages are Roku TVs