On Mon, Feb 08, 2021 at 08:08:33PM -0500, Theodore Ts'o 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. <blink> No, Ted, I did no such thing. Do you really think that I have so little respect for Gabriel, Amir or Jan or anyone else on -fsdevel that I would waste their precious time by behaving like a toxic, selfish, narcissistic asshole who cares only about a single filesystem to the exclusion of everything else? Maybe you haven't seen the big picture problem yet? That is, multiple actors have spoken of their need for a generic fs notification functionality and their requirements are not wholly centered around a single filesystem. The application stacks that need these notifications don't care what filesystem is being used to store the data; they just want to know when certain things happen to whatever filesystem their data is in and they want it in a single, common, well defined format. They most definitely do not want to have a N different ENOSPC message formats that they have to understand in userspace. They want one format that covers ENOSPC, shutdown, emergency remount-ro, inode corruption, data corruption, bad blocks, writeback failures, etc across all filesystems. This cannot be acheived by re-implmenting the notification wheel repeatedly in every filesystem we need to provide notifications from. Hence we need a notification subsystem that uses common messages for common events across ext4, ceph, btrfs, gfs2, NFS and other filesystems. There is nothing in what I described that is XFS specific, and quite frankly I don't give a shit about XFS here - I just used it as an example to derive a generic message format that covers a large number of the requirements we already have for information the notification subsystem needs to provide. So I'll make this very clear, because it is fundamental, non-negotiable requirement: *WE* *DO* *NOT* *WANT* *COMPETING* *FILESYSTEM* *NOTIFICATION* *SUBSYSTEMS* *IN* *THE* *KERNEL*. That means we have to work together to find common ground and a solution that works for everyone. What I've suggested allows all filesystems to supply the same information for the same events. It also allows filesystems to include their own private diagnostic information appended to the generic message, thereby fulfulling both the goals of both David Howells' original patchset and Gabriel's derived ext4 specific patchset. It works for everyone - it's a win-win scenario - and it lays the foundation for further common notifications to be created that are useful to userspace, as well as supporting customised filesystem specific notifications that largely makes it future proof. The design and message formats can be refined simply by collaborating to ensure that everyone's requirements are stated and met. If you have technical comments on this proposal, then I'm all ears. You know what Google's requirements for notifications are, so how about you go back to my email and respond with to whether the message format contains enough information for your employer's needs. This way we can improve the structure and ensure that the resulting message format and infrastructure design can do what everyone needs. I should not have to remind you of your responsibilities, Ted. Please try harder to understand what other people say and be truthful, respectful and constructive in future discussions. -Dave. -- Dave Chinner david@xxxxxxxxxxxxx
