shill can be rather spammy in some situations, so this isn't super surprising. Do you actually expect this is causing lifetime issues for the eMMC?

Looking a little closer: those basically look like normal scan reports, which get triggered when we're not connected to any Wifi networks. The steady-state scan timer behavior when disconnected is to scan once every minute, and a few messages about new/changed network info for each scan is not surprising. And in particular, these "suppressed" connections are noting that there are saved networks that were not found in these scans.

It doesn't seem like this is a request to change the scanning behavior. Once per minute doesn't seem excessive, when we aren't happy with the current Wifi state (disconnected). So the most I could recommend here is that we downgrade the priority of the "Suppressed autoconnect" messages so they don't show up at the default INFO level. It's not clear to me that we'd want to downgrade the other messages (e.g., BSS updates, as nearby networks come and go), so we wouldn't avoid all potential scanning-based logspam.

I *don't* see where rate limiting would be very helpful. I don't believe a sane rate limit would extend across the 1 minute scan intervals, and the repeats you see within a second or two are distinct pieces of information.

I'll repeat/rephrase my question from #2 though: are there guidelines for data writes for respecting flash lifetime? Let's say I approximate 11,682 messages per day as 1MB/day -- is that too much? What if we eliminated half of those (512KB/day) -- is that still too much?

#4: See https://bugs.chromium.org/p/chromium/issues/detail?id=912801#c30, these logs are not enough to explain the eMMC being worn out.
If you think the log frequency is acceptable/actionable, let's close the bugs.

It does look like we've suppressed some of the "suppressed" messages before ;)

https://gerrit.chromium.org/gerrit/38974

I'm semi-ambivalent about the "no endpoints" reason code logging; it's mostly self-evident, if you have enough context (we log when endpoints are discovered and removed). But it still could be useful in some cases, as it helps clarify services we could have connected to, if we could find them in scans.

But the frequency seems fine to me, so given #5...let's close.

On a related note, there are some low hanging fruits.  Dropping the log headers (i.e. [INFO:wifi.cc(320)]) can reduce the log size -- we do need to go through existing log messages to ensure there is no ambiguity after dropping headers. 

I would not prefer dropping the prefixes/headers. They're helpful for a lot of things, like turning up verbosity (e.g., ff_debug --level XX) and still telling the difference between ERROR and VERBOSE<N>. They also help to (implicitly) inform about the module that produced the log. Without that, there's a lot of logs we'd need to modify to be more specific I think.

And FWIW, syslog also includes log level (e.g., INFO/ERR/NOTICE). So those types of headers are not exactly abnormal practice.

Re #8:

We're not completely losing the level. INFO/WARNING/ERROR are actually repeated twice in net.log. The only thing we would lose is verbosity level as they mapped to DEBUG. But verbosity level isn't quite useful as, arguably, we haven't been very consistent about level.

Consider these

   DEBUG shill[4822]: [VERBOSE2:device_info.cc(692)] (device_info) AddLinkMsgHandler(index=1, flags=0x10049, change=0), new_device=0
   INFO shill[4822]: [INFO:wifi.cc(377)] ScanDone

becoming these

   DEBUG shill[4822]: (device_info) AddLinkMsgHandler(index=1, flags=0x10049, change=0), new_device=0
   INFO shill[4822]: ScanDone

The filenames and line numbers are also noisy. Rather than relying on them for precise locations of messages, the messages themselves should carry enough information.