linux-kernel - [RFC] ext3/jbd, kernel 2.6.13, make ext3 mountable as ext2 when journal is empty.

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-next>] [day] [month] [year] [list]

Date:	Wed, 9 Jul 2008 17:24:25 +0200
From:	"Jan Willem van den Brand" <janwillem.dev@...glemail.com>
To:	linux-kernel@...r.kernel.org
Subject: [RFC] ext3/jbd, kernel 2.6.13, make ext3 mountable as ext2 when journal is empty.

This patch makes ext3 mountable as ext2 even in case of a power
failure while mounted as ext3. We have tested it for kernel 2.6.13 but
it should be fairly easy to get it to work for other versions.

When mounting an ext3 file system as ext2 (without journalling) an
incompatibility flag is checked to assure that the journal can be
safely ignored. This INCOMPAT_RECOVER flag is set when ext3 is
unmounted. The idea is that, at this point, all checkpointing data is
transferred to disk.

In case of a power failure, the INCOMPAT flag is not reset. Systems
that suffer from frequent power failure (e.g. SD-cards that are
unsafely removed) will often not be mountable as ext2.

I think that ext3 can be mounted as ext2 when there is no
checkpointing data in the journal (no data being written from journal
to disk). The journal is then skipped by both e2fsck and ext3
mounting. To make aforementioned systems more frequently mountable as
ext2 we reset the INCOMPAT flag when we are sure that there is no
checkpointing data in the journal. We set it again as soon as there
is.

Furthermore, we observed that there is alsmost always checkpointing
data in the journal. Therefore, we flush the journal on every file
sync (journal flushing flushes checkppointing data) and we perform a
file sync after every file close.

Obviously, this solution will result in poor performance when many
small files are frequently closed after write but that is not the case
in our system (TomTom navigation device).

I'd like to hear opinions about this solution.

Best regards,

Jan Willem van den Brand

View attachment "patch.txt" of type "text/plain" (3874 bytes)