Re: [RFC] Filesystem error notifications proposal

[Khazhismel Kumykov <khazhy@google.com>]

[-- Attachment #1: Type: text/plain, Size: 2920 bytes --]

On Mon, Feb 8, 2021 at 5:08 PM Theodore Ts'o <tytso@mit.edu> wrote:
>
> On Tue, Feb 09, 2021 at 09:19:16AM +1100, Dave Chinner wrote:
> > Nope, not convinced at all. As a generic interface, it cannot be
> > designed explicitly for the needs of a single filesystem, especially
> > when there are other filesystems needing to implement similar
> > functionality.
> >
> > As Amir pointed up earlier in the thread, XFS already already has
> > extensive per-object verification and error reporting facilicities...
>
> Sure, but asking Collabora to design something which works for XFS and
> not for ext4 is also not fair.
>
> If we can't design something that makes XFS happy, maybe it will be
> better to design something specific for ext4.  Alternatively, perhaps
> the only thing that can be made generic is to avoid scope creep, and
> just design something which allows telling userspace "something is
> wrong with the file system", and leaving it at that.

It sounds like the two asks are pretty compatible, and we are
interested I think in some sort of generic reporting infra, rather
than re-inventing it separately for ext4, xfs, etc. (e.g., we've found
ENOSPC useful to get notifications for in tmpfs, so on...)

ext4 mostly needs filesystem-wide notification, passing
variable-length data, without sleeping, allocs, or unsafe locks? XFS
additionally wants per-mount and per-inode scopes? So, something that
notifies per-fs, and leaves open the possibility for mount & inode
scopes for those filesystems that desire it, w/ a generic "message"
format seems like the way to go? watch_queue or similar seems nice due
to not allocating. The seeming 128 byte limit per message though seems
too short if we want to be able to send strings or lots of metadata,
an alternative format with larger maximums seems necessary. (IMO this
is preferable to chaining 128 bytes notifications w/ 48 byte headers
each)

What to include in the "generic" header then becomes a hot topic... To
my naive eyes the suggested 6 fields don't seem outrageous, but an
alternative though could be just, it's all filesystem specific info,
leaving the only generic fields to be message type/version/length.
Since, regardless of the data you send, you can use the same generic
interface for hooking and preparing/sending the message. A fully
featured monitoring system would want to peek into per-fs data anyhow,
I'd think.

>
> But asking Collabora to design something for XFS, but doesn't work for
> ext4, is an absolute non-starter.
>
> > If we've already got largely standardised, efficient mechanisms for
> > doing all of this in a filesystem, then why would we want to throw
> > that all away when implementing a generic userspace notification
> > channel?
>
> You don't.  And if you want to implement something that works
> perfectly for xfs, but doesn't work for ext4, feel free.
>
> Cheers,
>
>                                         - Ted

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3996 bytes --]