linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexander Shishkin <alexander.shishckin@gmail.com>
To: Theodore Tso <tytso@mit.edu>
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 15:49:30 +0300	[thread overview]
Message-ID: <71a0d6ff0905120549h628146d8p3def31b09b79199a@mail.gmail.com> (raw)
In-Reply-To: <20090512121305.GL21518@mit.edu>

On 12 May 2009 15:13, Theodore Tso <tytso@mit.edu> wrote:
>> 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.

So, what Andreas explained yesterday also applies to the internal log
case. I see. Would you say it's possible to prevent this, for instance
somehow say, by means checksums as Andreas suggested?

> 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

It's an mmc and it (mkfs) runs almost two times faster without zeroing
the journal. The only thing I'm worried about is the time that it
takes for mke2fs -j to complete. I've done some caching trickery to
unix_io.c which I'm going to post here separately, but most of the
time seems to be taken by the journal.

> 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.

Hm. This might work, I'll look into it. Thanks for the idea!

Regards,
--
Alex
--
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

  reply	other threads:[~2009-05-12 12:49 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
2009-05-12 12:49           ` Alexander Shishkin [this message]
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=71a0d6ff0905120549h628146d8p3def31b09b79199a@mail.gmail.com \
    --to=alexander.shishckin@gmail.com \
    --cc=adilger@sun.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=sandeen@redhat.com \
    --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;
as well as URLs for NNTP newsgroup(s).