linux-ext4 - Re: ext4 settings in an embedded system

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:	Fri, 16 Nov 2012 17:18:01 +0100
From:	"Ohlsson, Fredrik (GE Healthcare, consultant)" 
	<Fredrik.Ohlsson@...com>
To:	"Artem Bityutskiy" <dedekind1@...il.com>,
	"Theodore Ts'o" <tytso@....edu>,
	"Eric Sandeen" <sandeen@...hat.com>
Cc:	<linux-ext4@...r.kernel.org>
Subject: Re: ext4 settings in an embedded system

Thank you very much for your helpful response and answers.

I would like to describe some background for our embedded system. The
system has recently been upgraded, before the upgrade we did not see
"filesystem" related problems. Before the upgrade we used  another
filesystem, kernel and IDE Flash Disk(kernel 2.6.12 kernel, reiserfs and
a smaller 256 MB IDE Flash Disk).  Today we have kernel 2.6.32,
ext4(default options) and a 1GB Transend TS1GDOM44H-S IDE Flash Disk.
We have a very low IO intensity towards the flash disk and low
requirements on the filesystem performance. 

In our case with the file of size 0 bytes. We use a bash shell script to
upgrade our application. The shell script calls the program "tar" and
tar overwrites/recreates  our application bin file. After some minutes
the power is cut and our bin file had the new size 0 bytes when the
system came up again . This particular case was solved by adding a sync
in the end of our upgrade shell script. I still don't understand why the
data is not committed to the disk after several minutes? Even if tar
leaves the file truncated tar must have closed the file and ext4 would
have done an implicit write-back?
We are worried that this will happen again where we use programs not
written by ourselves. Will the nodelalloc option solve this behavior?

If I understand you right the corrupted journal superblock (inode #8) is
most probably a result of a problem in the IDE Flash Disk.  I have
attached dumpe2fs.output from this problem. I booted the system from a
usb-drive and the filesystem could be repaired by e2fsck, but this is
not something the customer can do, we have to replace units like this.
The Transend TS1GDOM44H-S IDE Flash Disk is intended for demanding
embedded systems that require reliability, I guess it could still be the
part creating this problem. 

I think you are saying that ext4 should work fine in our setup were we
have regular power-cuts if we use sync/fsync and applies the following
settings:
-barrier, which we already use by default (Can't see barrier in the
attached dumpe2fs.output thou).
-nodelalloc
You also advise us to implement or own power-cut tests.

Are there more settings that could be to our favor, like
journal_checksum? Tune2fs data=journal?

Best Regards

Fredrik Ohlsson
Software Engineer

Download attachment "dumpe2fs.output" of type "application/octet-stream" (24139 bytes)

Download attachment "e2fsck.output" of type "application/octet-stream" (1895 bytes)