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

Message-ID: <50A65E5D.7040305@redhat.com>
Date:	Fri, 16 Nov 2012 09:40:13 -0600
From:	Eric Sandeen <sandeen@...hat.com>
To:	Andrey Sidorov <qrxd43@...orola.com>
CC:	dedekind1@...il.com,
	"Ohlsson, Fredrik (GE Healthcare, consultant)" 
	<Fredrik.Ohlsson@...com>, linux-ext4@...r.kernel.org
Subject: Re: ext4 settings in an embedded system

On 11/15/12 4:01 AM, Andrey Sidorov wrote:
> On Thu, Nov 15, 2012 at 12:42 PM, Artem Bityutskiy <dedekind1@...il.com> wrote:
> 
>> We conducted some 3 years ago. Results were quite good for ext4 - in
>> many cases it could recover without a need to run ckfs.ext4, sometimes
>> it was not mountable, but ckfs.ext4 helped.
>>
>> On the opposite, ext3 constantly required ckfs.ext3, and sometimes died
>> so badly that even ckfs.ext3 could not recover it.

Depending on your storage, if barriers were not enabled on your storage,
this is expected.  Evaporating write caches on power cut do not play well
with journaling guarantees.

https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Storage_Administration_Guide/writebarr.html

Barriers were not made default on ext3 until 2011, in kernel v3.1,
astonishingly.  So it makes sense that ext3 fared worse than ext4.

Unplayable journals are not surprising with non-battery-backed
writeback caches, no explicit cache flushing, and power loss.

> We ran about 6000 cycles of power resets with linux 2.6.37. The test
> was to run 3 tar processes unpacking linux kernel archive and power
> off after about 15 seconds. There were only 3 failures when file
> system couldn't be mounted, but that was due to HDD failure
> (unreadable sector in journal area). e2fsck successfully recovered
> those corruptions. As for software itself, there was no single issue
> and we never needed to run fsck after power loss. So I'd say that ext4
> is very tolerant to power losses at least in 2.6.37 assuming barriers
> and ordered data mode. I however understand this test is quite basic
> and any way results can be different for different kernels.

Right - barriers.

Of course you probably did lose *file* data even if the fs metadata
was correct.

Remember that journaling ensures a consistent metadata structure, but
does not guarantee data integrity.

-Eric
--
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