linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Lukas Czerner <lczerner@redhat.com>
Cc: linux-ext4@vger.kernel.org
Subject: Re: [PATCH v2] ext4: implement support for get/set fs label
Date: Wed, 1 Dec 2021 09:39:43 -0500	[thread overview]
Message-ID: <YaeJL8bOsGqBWR7P@mit.edu> (raw)
In-Reply-To: <20211130094950.ixqkxrjne6ldryeg@work>

On Tue, Nov 30, 2021 at 10:49:50AM +0100, Lukas Czerner wrote:
> > But after that?  I'd suggest not running the updates for the rest
> > through the journal at all, and just write them out directly.  Nothing
> > else will try to read or write the backup superblock blocks, so
> > there's no reason why we have to be super careful writing out the
> > rest.  If we crash after we've only updated the first 20 backup
> > superblocks --- that's probably 18 more than a user will actually use
> > in the first place.
> > 
> > That allows us to simply reserve 3 credits, and we won't need to try
> > to extend the handle, which means we don't have to implement some kind
> > of fallback logic in case the handle extension fails.
> 
> I think I agree. But in this case should we at least attempt to check
> and update the backup superblocks in fsck? Not sure if we do that
> already.

Well, after a successful file system check by fsck, we'll update all
of the backup superblocks.  If we've done a full file system check we
know that the primary superblock is consistent with the rest of the
file system, so at that point it's safe to write it to all of the
backup superblocks in the file system.

But if we haven't done the full file system check, we won't know
whether it is the primary or the backup superblock which is incorrect.
I guess we could do the basic superblock checks, and if there are at
least two additional superblocks, we see if we have do a 2 out of 3
voting check.  Or if there are differences between the primary and the
backup we could force a full check.

I think in practice though, so long as the primary and two backup
superblocks are part of the jbd2 transaction, that should be good
enough in terms of recovery since usually most users only use the
first backup superblock to recover if the primary is damaged.  Whether
we update the rest of the backup superblocks improves things, but it's
not really going to make a difference 99.99% of the time.

    	   	    	   	      	     - Ted

  reply	other threads:[~2021-12-01 14:42 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-11 21:59 [PATCH] ext4: implement support for get/set fs label Lukas Czerner
2021-11-12  8:20 ` [PATCH v2] " Lukas Czerner
2021-11-29 20:28   ` Andreas Dilger
2021-11-29 20:49     ` Lukas Czerner
2021-11-30  3:00   ` Theodore Y. Ts'o
2021-11-30  9:49     ` Lukas Czerner
2021-12-01 14:39       ` Theodore Y. Ts'o [this message]
2021-12-10 15:16   ` [PATCH v3] " Lukas Czerner
2021-12-10 15:22     ` Lukas Czerner
2021-12-10 23:05       ` Theodore Y. Ts'o
2021-12-13  9:44         ` Lukas Czerner
2021-12-10 18:48     ` [PATCH v4] " Lukas Czerner
2021-12-13 13:56       ` [PATCH v5] " Lukas Czerner
2022-01-05  3:14         ` Theodore Ts'o

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=YaeJL8bOsGqBWR7P@mit.edu \
    --to=tytso@mit.edu \
    --cc=lczerner@redhat.com \
    --cc=linux-ext4@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 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).