All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Dave Chinner <david@fromorbit.com>
Cc: "Darrick J. Wong" <djwong@kernel.org>,
	linux-xfs@vger.kernel.org, cem@kernel.org,
	Christoph Hellwig <hch@lst.de>
Subject: Re: [RFC] xfs: opting in or out of online repair
Date: Thu, 25 Jul 2024 16:14:13 +0200	[thread overview]
Message-ID: <20240725141413.GA27725@lst.de> (raw)
In-Reply-To: <ZqGy5qcZAbHtY61r@dread.disaster.area>

On Thu, Jul 25, 2024 at 12:05:26PM +1000, Dave Chinner wrote:
> Maybe I'm missing something important - this doesn't feel like
> on-disk format stuff. Why would having online repair enabled make
> the fileystem unmountable on older kernels?

Yes, that's the downside of the feature flag.

> Hmmm. Could this be implemented with an xattr on the root inode
> that says "self healing allowed"?

The annoying thing about stuff in the public file system namespace
is that chowning the root of a file system to a random user isn't
that uncommon, an that would give that user more privileges than
intended.  So it could not hust be a normal xattr but would have
to be a privileged one, and with my VFS hat on I'd really like
to avoid creating all these toally overloaded random non-user
namespace xattrs that are a complete mess.

One option would be an xattr on the metadir root (once we merge
that, hopefully for 6.12).  That would still require a new ioctl
or whatever interface to change (or carve out an exception to
the attr by handle interface), but it would not require kernel
and tools to fully understand it.

> > Note that administrator-initated scans (e.g. invoking xfs_scrub from the
> > CLI) would not be blocked by this flag.
> > 
> > Question: Should this compat flag control background scrubs as well?
> 
> Probably. scrub is less intrusive, but I can see people wanting to
> avoid it because it can have a perf impact. Could this be done with
> a different xattr on the root inode?

Yes, scrub vs repair should probably be separate.


  reply	other threads:[~2024-07-25 14:14 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-24 21:38 [RFC] xfs: opting in or out of online repair Darrick J. Wong
2024-07-25  2:05 ` Dave Chinner
2024-07-25 14:14   ` Christoph Hellwig [this message]
2024-07-25 22:33     ` Dave Chinner
2024-07-26  0:41       ` Darrick J. Wong
2024-07-26  1:15         ` Dave Chinner
2024-07-26 13:59         ` Christoph Hellwig
2024-07-26 15:15           ` Darrick J. Wong

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=20240725141413.GA27725@lst.de \
    --to=hch@lst.de \
    --cc=cem@kernel.org \
    --cc=david@fromorbit.com \
    --cc=djwong@kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.