linux-ext4 - Re: A question on umounting without flushing journal

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

Date:   Tue, 3 Mar 2020 12:30:38 -0500
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     Bo Branten <bosse@....umu.se>
Cc:     linux-ext4@...r.kernel.org
Subject: Re: A question on umounting without flushing journal

On Tue, Mar 03, 2020 at 11:26:13AM +0100, Bo Branten wrote:
> 
> now I have another question on how to test the ext4 driver we implement for
> another os: At mount time the driver should check the journal and use jbd2
> to replay if there is anything left in it and I would like to ask if there
> is any other methods to do an unclean umount in linux besides pressing
> reset? I would like to leave a lot of records in the journal that our driver
> can try to process?

The standard way to do this in xfstests is using the dm-flakey
device-mapper device.  We set it up so that all reads and writes are
passed through, and then we start some workload such as fsstress, and
then we reconfigure dm-flakey to drop 100% of all write requests to
the underlying block device.

We then kill the workload, and unmount the file system, and then we
reset the dm-flakey device to pass through 100% of all writes.  This
simulates quite accurately what the block device would look like after
a sudden power failure, but it doesn't require a power-fail rack
(without shortening the lives of the equipment; dropping power tends
to put a lot stress on the hardware).

Cheers,

					- Ted