On Mon, Feb 8, 2021 at 5:08 PM Theodore Ts'o <tytso@xxxxxxx> 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:
smime.p7s
Description: S/MIME Cryptographic Signature
