linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Theodore Ts'o <tytso@mit.edu>
Cc: Dave Chinner <david@fromorbit.com>,
	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 18:32:30 -0800	[thread overview]
Message-ID: <20210210023230.GF7187@magnolia> (raw)
In-Reply-To: <YCNDNEc2KBsi8g4L@mit.edu>

On Tue, Feb 09, 2021 at 09:21:40PM -0500, Theodore Ts'o wrote:
> On Tue, Feb 09, 2021 at 04:52:07PM -0800, Darrick J. Wong wrote:
> > 
> > I definitely don't want to implement string parsing for xfs_scrub.
> > 
> > The kernel already has enough information to fill out the struct
> > xfs_scrub_metadata structure for userspace in case it decides to repair.
> 
> I suspect anything which is specific enough for xfs_scrub is going to
> be *significantly* file system dependent.  And in the past, attempts
> to do some kind of binary tag-length-value scheme has generally gotten
> vetoed.  If it's just "there's something wrong with inode number 42",
> that's one thing.  But if it's, "position 37 of the 3rd btree interior
> node is out of order", how in the world is that supposed to be
> generic?
> 
> Taking a step back, it seems that there are a number of different use
> cases that people have been discussing on this thread.  One is
> "there's something wrong with the file system", so the file system
> should be taken off-line for repair and/or fail over the primary
> server to the secondary/backup server.
> 
> Yet another use case might be "the file system is getting full, so
> please expand the LVM and resize the file system".  (This is a bit
> more complex since different system administrators and different
> systems may want different trigger points, from 75%, 80%, 95%, or
> "we've already delivered ENOSPC to the application so there are
> user-visible failures", but presumably this can be configured, with
> perhaps sime fixed number of configured trigger points per file
> system.)
> 
> Both of these are fairly generic, and don't required exposing a file
> system's detailed, complex object hierarchies to userspace.  But if
> the goal is pushing out detailed metadata information sufficient for
> on-line file system repair, that both seems to be a massive case of
> scope creep, and very much file system specific, and not something
> that could be easily made generic.
> 
> If the XFS community believes it can be done, perhaps you or Dave
> could come up with a specific proposal, as opposed to claiming that
> Gabriel's design is inadequate because it doesn't meet with XFS's use
> case?  And perhaps this is a sufficiently different set of
> requirements that it doesn't make sense to try to have a single design
> that covers all possible uses of a "file system notification system".

I did in [1], but vger is being slow and hasn't yet delivered it to me
yet.  At least they try to hit lore first now, I guess?

--D

[1] https://lore.kernel.org/linux-fsdevel/20210210000932.GH7190@magnolia/T/#m268c5a244cb7bd749b9c029e1d7c3f00d194b181

> Regards,
> 
> 					- Ted

  reply	other threads:[~2021-02-10  2:35 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
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 [this message]
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=20210210023230.GF7187@magnolia \
    --to=djwong@kernel.org \
    --cc=amir73il@gmail.com \
    --cc=darrick.wong@oracle.com \
    --cc=david@fromorbit.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).