linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Theodore Ts'o <tytso@mit.edu>
Cc: Gabriel Krisman Bertazi <krisman@collabora.com>,
	jack@suse.com, viro@zeniv.linux.org.uk, amir73il@gmail.com,
	dhowells@redhat.com, darrick.wong@oracle.com, khazhy@google.com,
	linux-fsdevel@vger.kernel.org, kernel@collabora.com
Subject: Re: [RFC] Filesystem error notifications proposal
Date: Tue, 9 Feb 2021 19:55:01 +1100	[thread overview]
Message-ID: <20210209085501.GS4626@dread.disaster.area> (raw)
In-Reply-To: <YCHgkReD1waTItKm@mit.edu>

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@fromorbit.com

  parent reply	other threads:[~2021-02-09  8:58 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-20 20:13 [RFC] Filesystem error notifications proposal Gabriel Krisman Bertazi
2021-01-21  4:01 ` Viacheslav Dubeyko
2021-01-21 11:44 ` Jan Kara
2021-01-21 13:27   ` Amir Goldstein
2021-01-21 18:56   ` Gabriel Krisman Bertazi
2021-01-21 22:44 ` Theodore Ts'o
2021-01-22  0:44   ` Gabriel Krisman Bertazi
2021-01-22  7:36     ` Amir Goldstein
2021-02-02 20:51       ` Gabriel Krisman Bertazi
2021-01-28 22:28     ` Theodore Ts'o
2021-02-02 20:26       ` Gabriel Krisman Bertazi
2021-02-02 22:34         ` Theodore Ts'o
2021-02-08 18:49           ` Gabriel Krisman Bertazi
2021-02-08 22:19             ` Dave Chinner
2021-02-09  1:08               ` Theodore Ts'o
2021-02-09  5:12                 ` Khazhismel Kumykov
2021-02-09  8:55                 ` Dave Chinner [this message]
2021-02-09 17:57                   ` Theodore Ts'o
2021-02-10  0:52                     ` Darrick J. Wong
2021-02-10  2:21                       ` Theodore Ts'o
2021-02-10  2:32                         ` Darrick J. Wong
2021-02-09 17:35               ` Jan Kara
2021-02-10  0:22                 ` Darrick J. Wong
2021-02-10  7:46                 ` Dave Chinner
2021-02-10  0:49               ` Darrick J. Wong
2021-02-10  0:09 ` Darrick J. Wong
2021-02-10  7:23   ` Amir Goldstein
2021-02-10 23:29   ` Gabriel Krisman Bertazi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210209085501.GS4626@dread.disaster.area \
    --to=david@fromorbit.com \
    --cc=amir73il@gmail.com \
    --cc=darrick.wong@oracle.com \
    --cc=dhowells@redhat.com \
    --cc=jack@suse.com \
    --cc=kernel@collabora.com \
    --cc=khazhy@google.com \
    --cc=krisman@collabora.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=tytso@mit.edu \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).