search

openzfs / zfs

OpenZFS on Linux and FreeBSD
https://openzfs.github.io/openzfs-docs
Other
10.64k stars 1.75k forks source link

Create a --no-log feature to allow elimination of certain logging events. #13376

Open NathanaelA opened 2 years ago

NathanaelA commented 2 years ago

Describe the feature would like to see added to OpenZFS

The Import, send, mount, load-key, destroy are all noisy and honestly don't appear to provide me any info that I'm ever looking for in the log in my overall usage of the log . I would love to be able to optionally add a --no-log to certain commands to eliminate the logging of them just to keep my logs clean and keep them from over writing older entries on systems that have smaller log buffers.

How will this feature improve OpenZFS?

Eliminates extraneous un-useful logging

Additional context

Related to: https://github.com/openzfs/zfs/issues/13126

I'd be willing to try and create a PR for this feature --no-log where it by default the only event that can't be --no-log is create as my understanding is this event is actually required to be present in the log as the first entry. Thoughts, on if it would be accepted -- I don't really want to waste the time to do a PR if the team is against a feature like this?

szubersk commented 2 years ago

Import, send, mount, load-key, destroy

As established in previous discussions, we have to log operations that change the state of a pool/filesystem. Send, mount and load-key shouldn't be logged at all. Imports and destructions should be logged always. A relief could be brought by adding filter options to zpool history command so certain operations won't be printed out without losing them from the log (security reasons).

Would you mind sharing example history log from your pool so we can see what level of churn we're talking about?

NathanaelA commented 2 years ago

@szubersk - I looked at 13126, and wasn't sure a consensuses was got to, before I added this "feature" request. :grinning:

However, destroys on snapshots are my 2nd largest number of logged items. I would love to be able to ignore at least all snapshot related activities (including its destroy), as this will still cause a small log to wrap and will have no effect on still losing items which the extra filtering on zpool history won't help if the logged items are gone. The objective is to eliminate noise in the log...

However, lets for just for simplicity sake say that destroy/import are off the table currently for removal from logging, so we don't have to argue the validity of those. I would like to at least proceed on the items we are in agreement on. :grinning:

So, then I guess I need to know a couple things, because I'm willing to start playing with creating at eliminating of logging PR. Do we just not want to log any load-key, unload-key, mount, send or do we not want to log it only if a --no-log is passed. Thoughts? There might be people who actually want the extra logging, so I'm not opposed to making the extra logging removal a opt-out option (i.e. --no-log or a configuration setting) ...

rincebrain commented 2 years ago

I would pretty strongly argue against this.

I dislike the idea of letting userland decide when to log something or not - I would like the features to be useful, but I would also not like to encounter a situation where someone says "why is this snapshot gone" and the history log says [crickets] because everyone defaults to not logging any more, so you don't know if something mangled the metadata, or someone ran a destroy, or...

NathanaelA commented 2 years ago

@rincebrain - I understand Rich, which is why I said lets take the import/destroy off the table (meaning lets not worry about them at this point) as even some incremental improvements to the logging are better than none. :grinning:

I assume you aren't against eliminating the logging for the other items 'load-key', 'mount', 'send', etc. So my question going forward is does the team want them totally dropped, because they serve little to no purpose in the log, or by default logged and only dropped if the --no-log is passed. This way I have some idea which way to proceed on a PR that would have the most likely hood of being accepted. :grinning:

szubersk commented 2 years ago

@NathanaelA Rich already proposed implementation of 2 different history buffers (so "the churn" is still tracked but not affecting other types of history entries) in #13374. If you are interested in analysis and implementation of the proposed functionality I'd suggest continuing the discussion there and closing this report (we already have 3 ticket reported about the same issue, let's keep the red-tape in check).