Re: [PATCH v9 00/31] file system-wide error monitoring

Amir Goldstein [off-list ref] writes:

On Wed, Oct 27, 2021 at 2:22 PM Jan Kara [off-list ref] wrote:

quoted

On Tue 26-10-21 12:12:38, Amir Goldstein wrote:

quoted

On Mon, Oct 25, 2021 at 10:27 PM Gabriel Krisman Bertazi
[off-list ref] wrote:

quoted

Hi,

This is the 9th version of this patch series.  Thank you, Amir, Jan and
Ted, for the feedback in the previous versions.

The main difference in this version is that the pool is no longer
resizeable nor limited in number of marks, even though we only
pre-allocate 32 slots.  In addition, ext4 was modified to always return
non-zero errno, and the documentation was fixed accordingly (No longer
suggests we return EXT4_ERR* values.

I also droped the Reviewed-by tags from the ext4 patch, due to the
changes above.

Please let me know what you think.

All good on my end.
I've made a couple of minor comments that
could be addressed on commit if no other issues are found.

All good on my end as well. I've applied all the minor updates, tested the
result and pushed it out to fsnotify branch of my tree. WRT to your new
FS_ERROR LTP tests, I've noticed that the testcases 1 and 3 from test
fanotify20 fail for me. After a bit of debugging this seems to be a bug in
ext4 where it calls ext4_abort() with EXT4_ERR_ESHUTDOWN instead of plain
ESHUTDOWN. Not sure if you have that fixed or how come the tests passed for
you. After fixing that ext4 bug everything passes for me.

Gabriel mentioned that bug in the cover letter of the LTP series :-)
https://lore.kernel.org/linux-ext4/20211026173302.84000-1-krisman@collabora.com/T/#u

Yes :)

Also, thank you both for the extensive review and ideas during the
development of this series.  It was really appreciated!

I'm sending out the new version for tests + man pages today.

-- 
Gabriel Krisman Bertazi

Also, thank you both for the extensive review and ideas during the
development of this series.  It was really appreciated!

Thank you for your appreciated effort!
It was a wild journey through some interesting experiments, but
you survived it well ;-)

Would you be interested in pursuing FAN_WB_ERROR after a due rest
and after all the dust on FAN_FS_ERROR has settled?

FAN_WB_ERROR can use the same info record and same internal
error event struct as FAN_FS_ERROR.

A call to fsnotify_wb_error(sb, inode, err) can be placed inside
mapping_set_error() and maybe for other sporadic callers of errseq_set().

For wb error, we can consider storing a snapshot of errseq of the sb/inode
in the sb/inode mark and compute error_count from the errseq diff
instead of counting it when merging events. This will keep a more accurate
report even when error reports are dropped due to allocation failure or event
queue overflow.

I have a feeling that the Postgres project would find this
functionality useful (?).

Thanks,
Amir.