From: "Lukáš Czerner" <lczerner@redhat.com>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: "Ext4 Developers List" <linux-ext4@vger.kernel.org>,
"Андрей Василишин" <a.vasilishin@kpi.ua>,
"Jon Severinsson" <jon@severinsson.net>,
744953@bugs.debian.org
Subject: Re: [PATCH] e2fsck: reopen the file system with saved flags after a journal replay
Date: Tue, 8 Jul 2014 14:49:55 +0200 (CEST) [thread overview]
Message-ID: <alpine.LFD.2.00.1407081448530.2180@localhost.localdomain> (raw)
In-Reply-To: <20140708115827.GB27440@thunk.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1891 bytes --]
On Tue, 8 Jul 2014, Theodore Ts'o wrote:
> Date: Tue, 8 Jul 2014 07:58:27 -0400
> From: Theodore Ts'o <tytso@mit.edu>
> To: Lukáš Czerner <lczerner@redhat.com>
> Cc: Ext4 Developers List <linux-ext4@vger.kernel.org>,
> Андрей Василишин <a.vasilishin@kpi.ua>,
> Jon Severinsson <jon@severinsson.net>, 744953@bugs.debian.org
> Subject: Re: [PATCH] e2fsck: reopen the file system with saved flags after a
> journal replay
>
> On Tue, Jul 08, 2014 at 11:03:53AM +0200, Lukáš Czerner wrote:
> > > + ctx->openfs_flags = flags;
> > > retval = try_open_fs(ctx, flags, io_ptr, &fs);
> >
> > Maybe we can get rid of 'flags' argument since it's not needed
> > anymore ?
>
> Yeah, I thought of that, but I was trying to keep the patch small,
> since I thought this was one that distros might want to cherry pick.
Makes sense.
>
> > Otherwise the patch looks good, however for some reason I can not
> > reproduce the problem in the big file system (without bigalloc) even
> > though looking at bitmap.c it looks like we really should get that
> > error.
>
> Ah, yes, in the big file system case we don't hit it because we don't
> actually load the bitmaps before we close and reopen the file system
> again. But in the bigalloc case, we check and fail at openfs time,
> which aborts the fsck run.
>
> So we could work around this by moving the bigalloc check to when we
> open the file system, but you want get the other openfs flags right,
> especially the EXT2_FLAG_SKIP_MMP flags.
Yep, I agree with the fix, I was just wondering about the big fs
case. Anyway you can add:
Reviewed-by: Lukas Czerner <lczerner@redhat.com>
>
> Cheers,
>
> - Ted
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
next prev parent reply other threads:[~2014-07-08 12:50 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-06 3:09 [PATCH] e2fsck: reopen the file system with saved flags after a journal replay Theodore Ts'o
2014-07-08 9:03 ` Lukáš Czerner
2014-07-08 11:58 ` Theodore Ts'o
2014-07-08 12:49 ` Lukáš Czerner [this message]
2014-07-08 17:29 ` Darrick J. Wong
-- strict thread matches above, loose matches on Subject: below --
2014-07-06 3:12 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=alpine.LFD.2.00.1407081448530.2180@localhost.localdomain \
--to=lczerner@redhat.com \
--cc=744953@bugs.debian.org \
--cc=a.vasilishin@kpi.ua \
--cc=jon@severinsson.net \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
/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