From: Theodore Tso <tytso@mit.edu>
To: Alexander Shishkin <alexander.shishckin@gmail.com>
Cc: Eric Sandeen <sandeen@redhat.com>,
Andreas Dilger <adilger@sun.com>,
linux-ext4@vger.kernel.org
Subject: Re: [Q] ext3 mkfs: zeroing journal blocks
Date: Tue, 12 May 2009 08:13:06 -0400 [thread overview]
Message-ID: <20090512121305.GL21518@mit.edu> (raw)
In-Reply-To: <71a0d6ff0905120455x291d7280ybe8d1a562987fd1b@mail.gmail.com>
On Tue, May 12, 2009 at 02:55:10PM +0300, Alexander Shishkin wrote:
> On 11 May 2009 21:44, Eric Sandeen <sandeen@redhat.com> wrote:
> > Andreas Dilger wrote:
> >
> >> The reason that the journal is zeroed is because there is some chance
> >> that old (valid at the time) transaction headers and commit blocks might
> >> be in the journal and could accidentally be "recovered" and cause bad
> >> corruption of the filesystem.
> >
> > But I guess the question is, why isn't a normal internal log zeroed?
> >
> > If I'm reading it right only external logs get this treatment, and I
> > think that's what generated the original question from Alexander.
>
> My concern was basically if it is safe to skip zeroing for internal journal.
Strictly speaking, no. Most of the time you'll get lucky. The place
where you will get into trouble will be is if there is leftover
uninitialized garbage (particularly if you are reformatting an
existing ext3/4 filesystem) that looks like a journal log block, with
the correct journal transaction number, *and* the system crashes
before the journal has been completely written through at least once.
What precisely is your concern? Normally the journal isn't that big,
and it's a contiguous write --- so it doesn't take that long. Are you
worried about the time it takes, or trying to avoid some writes to an
SSD, or some other concern? If we know it's an SSD, where reads are
fast, and writes are slow, I suppose we could scan the disk looking
for potentially dangerous blocks and zero them manually. It's really
not clear it's worth the effort though.
- Ted
next prev parent reply other threads:[~2009-05-12 12:13 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-11 15:03 [Q] ext3 mkfs: zeroing journal blocks Alexander Shishkin
2009-05-11 17:58 ` Eric Sandeen
2009-05-11 18:20 ` Andreas Dilger
2009-05-11 18:44 ` Eric Sandeen
2009-05-11 19:35 ` Theodore Tso
2009-05-11 19:35 ` Andreas Dilger
2009-05-12 11:55 ` Alexander Shishkin
2009-05-12 12:13 ` Theodore Tso [this message]
2009-05-12 12:49 ` Alexander Shishkin
2009-05-12 21:04 ` Theodore Tso
2009-07-29 15:58 ` [PATCH] [RFC] mkjournal: zero journal blocks only when necessary Alexander Shishkin
2009-07-29 17:16 ` Theodore Tso
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=20090512121305.GL21518@mit.edu \
--to=tytso@mit.edu \
--cc=adilger@sun.com \
--cc=alexander.shishckin@gmail.com \
--cc=linux-ext4@vger.kernel.org \
--cc=sandeen@redhat.com \
/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).