linux-ext4 - Re: [Q] ext3 mkfs: zeroing journal blocks

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 12 May 2009 15:49:30 +0300
From:	Alexander Shishkin <alexander.shishckin@...il.com>
To:	Theodore Tso <tytso@....edu>
Cc:	Eric Sandeen <sandeen@...hat.com>,
	Andreas Dilger <adilger@....com>, linux-ext4@...r.kernel.org
Subject: Re: [Q] ext3 mkfs: zeroing journal blocks

On 12 May 2009 15:13, Theodore Tso <tytso@....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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html