All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: "Darrick J. Wong" <djwong@kernel.org>, Brian Foster <bfoster@redhat.com>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH 07/10] xfs_repair: set NEEDSREPAIR when we deliberately corrupt directories
Date: Wed, 10 Feb 2021 14:19:15 -0600	[thread overview]
Message-ID: <e585830c-d5d3-d9fd-1bfb-e9bfde255797@sandeen.net> (raw)
In-Reply-To: <20210209194317.GY7193@magnolia>

On 2/9/21 1:43 PM, Darrick J. Wong wrote:
> On Tue, Feb 09, 2021 at 02:14:22PM -0500, Brian Foster wrote:
>> On Tue, Feb 09, 2021 at 10:35:42AM -0800, Darrick J. Wong wrote:
>>> On Tue, Feb 09, 2021 at 12:20:59PM -0500, Brian Foster wrote:
>>>> On Mon, Feb 08, 2021 at 08:10:44PM -0800, Darrick J. Wong wrote:
>>>>> From: Darrick J. Wong <djwong@kernel.org>
>>>>>
>>>>> There are a few places in xfs_repair's directory checking code where we
>>>>> deliberately corrupt a directory entry as a sentinel to trigger a
>>>>> correction in later repair phase.  In the mean time, the filesystem is
>>>>> inconsistent, so set the needsrepair flag to force a re-run of repair if
>>>>> the system goes down.
>>>>>
>>>>> Signed-off-by: Darrick J. Wong <djwong@kernel.org>
>>>>> ---
>>>>
>>>> Hmm.. this seems orthogonal to the rest of the series. I'm sure we can
>>>> come up with various additional uses for the bit, but it seems a little
>>>> odd to me that repair might set it in some cases after a crash but not
>>>> others (if the filesystem happens to already be corrupt, for example).
>>>
>>> <nod> Another option I thought of is to add a hook to the buffer cache
>>> so that the first time anyone tries to bwrite a buffer (either directly
>>> or via a delwri list or normal buffer cache writeback) we'll also set
>>> needsrepair on the ondisk primary super.  That would protect us against
>>> other scenarios like crashing after writing a new AGF but before writing
>>> the new AGI, where the fs is left in an indeterminate state.
>>>
>>
>> Yeah, that _seems_ more appropriate to me. It's not immediately clear to
>> me what the implementation should look like, but in general behavior
>> that sets needsrepair on first modification and clears it as a final
>> step sounds more practical. Then the behavior can be easily explained as
>> "once repair starts on an fs, it must be completed before it is allowed
>> to mount." I do think this should be lifted off for a followon series so
>> we can make progress on the feature upgrade bits without growing more
>> requirements and complexity..
> 
> Oh, definitely. I'll withdraw this patch for now in the interests of
> getting everything else going for Eric. :)

Noted, I'll drop this one for now, thanks.

-Eric

  reply	other threads:[~2021-02-10 20:20 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-09  4:10 [PATCHSET v4 00/10] xfs: add the ability to flag a fs for repair Darrick J. Wong
2021-02-09  4:10 ` [PATCH 01/10] xfs_admin: clean up string quoting Darrick J. Wong
2021-02-09  9:07   ` Christoph Hellwig
2021-02-09  4:10 ` [PATCH 02/10] xfs_admin: support filesystems with realtime devices Darrick J. Wong
2021-02-09  9:08   ` Christoph Hellwig
2021-02-09 17:19   ` Brian Foster
2021-02-09  4:10 ` [PATCH 03/10] xfs_db: support the needsrepair feature flag in the version command Darrick J. Wong
2021-02-09  9:09   ` Christoph Hellwig
2021-02-09 17:15     ` Darrick J. Wong
2021-02-09 17:19   ` Brian Foster
2021-02-09  4:10 ` [PATCH 04/10] xfs_repair: fix unmount error message to have a newline Darrick J. Wong
2021-02-09  9:09   ` Christoph Hellwig
2021-02-09  4:10 ` [PATCH 05/10] xfs_repair: clear quota CHKD flags on the incore superblock too Darrick J. Wong
2021-02-09  9:10   ` Christoph Hellwig
2021-02-09 17:20   ` Brian Foster
2021-02-09 17:46     ` Darrick J. Wong
2021-02-09  4:10 ` [PATCH 06/10] xfs_repair: clear the needsrepair flag Darrick J. Wong
2021-02-09  9:12   ` Christoph Hellwig
2021-02-09 17:20   ` Brian Foster
2021-02-09 18:01     ` Darrick J. Wong
2021-02-09  4:10 ` [PATCH 07/10] xfs_repair: set NEEDSREPAIR when we deliberately corrupt directories Darrick J. Wong
2021-02-09  9:13   ` Christoph Hellwig
2021-02-09 18:45     ` Darrick J. Wong
2021-02-09 17:20   ` Brian Foster
2021-02-09 18:35     ` Darrick J. Wong
2021-02-09 19:14       ` Brian Foster
2021-02-09 19:43         ` Darrick J. Wong
2021-02-10 20:19           ` Eric Sandeen [this message]
2021-02-09  4:10 ` [PATCH 08/10] xfs_repair: allow setting the needsrepair flag Darrick J. Wong
2021-02-09  9:15   ` Christoph Hellwig
2021-02-09 14:41     ` Eric Sandeen
2021-02-09 16:47       ` Darrick J. Wong
2021-02-10 20:44         ` Eric Sandeen
2021-02-09 17:21   ` Brian Foster
2021-02-09 18:10     ` Darrick J. Wong
2021-02-10 20:26       ` Eric Sandeen
2021-02-09  4:10 ` [PATCH 09/10] xfs_repair: add a testing hook for NEEDSREPAIR Darrick J. Wong
2021-02-09  9:16   ` Christoph Hellwig
2021-02-09 17:21   ` Brian Foster
2021-02-09 18:17     ` Darrick J. Wong
2021-02-09 18:59       ` Brian Foster
2021-02-09 19:59         ` Darrick J. Wong
2021-02-09 20:32           ` Brian Foster
2021-02-10 21:41           ` Eric Sandeen
2021-02-11  1:30             ` Darrick J. Wong
2021-02-09  4:11 ` [PATCH 10/10] xfs_admin: support adding features to V5 filesystems Darrick J. Wong
2021-02-09  9:18   ` Christoph Hellwig
2021-02-09 17:22   ` Brian Foster
2021-02-09 18:22     ` 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=e585830c-d5d3-d9fd-1bfb-e9bfde255797@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=bfoster@redhat.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.