Reduce FUSE transport log level.#225
Conversation
The FUSE init flags are unlikely to be of use unless one is debugging a problem with the filesystem. The messages about channel status get printed for every thread, and it's rather confusing for end-users to have a FUSE filesystem terminate with: fuse filesystem umounted FUSE channel already closed! FUSE channel already closed! FUSE channel already closed! FUSE channel already closed! FUSE channel already closed! FUSE channel already closed! ...when everything went well.
| info!( | ||
| debug!( | ||
| "FUSE INIT major {} minor {}\n in_opts: {:?}\nout_opts: {:?}", | ||
| major, minor, capable, enabled |
There was a problem hiding this comment.
LGTM, but in real-world usage scenario, we'd like this info (Business processe usually only enable info-level logging) to always be visible to make it easier to debug fuse-related issues across different kernels.
There was a problem hiding this comment.
Would it make more sense to expose this somewhere via some getter and then have that application log it explicitly?
See my question regarding that on #195 (comment)
Logging this with info level is surprising for library consumers, and confusing for end users. It really should be exposed through some getter, if you want to print these values explicitly from one application.
There was a problem hiding this comment.
👍 I think it's reasonable to provide a getter so that the business process can print it as needed.
The FUSE init flags are unlikely to be of use unless one is debugging a problem with the filesystem.
The messages about channel status get printed for every thread, and it's rather confusing for end-users to have a FUSE filesystem terminate with:
fuse filesystem umounted
FUSE channel already closed!
FUSE channel already closed!
FUSE channel already closed!
FUSE channel already closed!
FUSE channel already closed!
FUSE channel already closed!
...when everything went well.
NOTE: This is a rebase of #200