-
Notifications
You must be signed in to change notification settings - Fork 3
Description
Currently, if something goes wrong while using the library all you have to go on is the Ext4Error it produces (assuming that it does return an error). A notable area that isn't handled well currently is reading the journal. The code is fairly lenient about corruption errors, because it's allowed for a journal to be cut off unexpectedly (e.g. due to sudden power loss). However, what if the code has a bug and is incorrectly swallowing some errors? We'd have no way to see it, unless it causes some downstream problem when reading the filesystem.
More generally, as seen in #389 (comment), a user might run into unexpected behavior but not be able to share the filesystem. Logging could help provide insight into user problems.
I'm imagining that logging would be fairly verbose, and rarely of interest except when debugging. So we'd put it at the Trace level.
Since filesystems can contain sensitive data, we should avoid logging paths or the contents of data blocks.