linux-ext4 - Re: Fast ext4 cleanup to avoid data loss after power failure

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 for Android: free password hash cracker in your pocket

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

Message-ID: <543311D2.10102@pqgruber.com>
Date:	Tue, 07 Oct 2014 00:04:02 +0200
From:	Clemens Gruber <clemens.gruber@...ruber.com>
To:	Theodore Ts'o <tytso@....edu>
CC:	linux-ext4@...r.kernel.org
Subject: Re: Fast ext4 cleanup to avoid data loss after power failure

Thank you very much for your thorough response, Ted! It helped me out a
lot. Also big thanks to Lukáš and Eric!

At the moment I am changing every application state update to an atomic
"fwrite to tempfile, fsync (or fdatasync) tempfile, rename, fsync parent
dir".
As the amount of writes I need for application updates is usually small
(1-3 fwrites), I decided to update the application state file without an
extra journal log for now. But if the amount of necessary writes grows,
then I'll introduce a journal log file to minimize the writes needed for
each application state update.
Or would you consider adding an application level journal anyway?

So after following this design pattern for the application and locking
the filesystem with FIFREEZE before the power fails, does it matter what
flags I set for the ext4 filesystem?
Should I stay with the default settings data=ordered and commit=5?

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