Re: [BUG] Big fiability issue?

[Edward Shishkin <edward.shishkin@gmail.com>]

Hello Ivan,

Write barriers mean a proper ordering of writes. This is needed to
guarantee consistency. For example, commit record should be written
*after* writes of all journal blocks, etc. In reiser4 write barriers
are always "on" by design.

There were 2 ways to provide such ordering: hardware and software
ones. The hardware way assumes additional supports from the hard
drive and the block layer. The Linux block layer had had such support
~6 years ago, however it was dropped then:
https://lwn.net/Articles/400541/
See also Linux/Documentation/block/barrier.txt in old kernels

Respectively, we should discontinue the "hardware barriers" support
in reiser4 and unconditionally switch to the software implementation
that we have for devices without hardware barriers support. I forgot
to make such switch in due time.

Thanks,
Edward.

On 04/06/2016 02:23 AM, Ivan Shapovalov wrote:
> On 2016-04-05 at 17:43 +0200, Edward Shishkin wrote:
>> Hello Mathieu,
>>
>> I found that by default reiser4 still relies on a block layer
>> feature,
>> which is not longer supported. This is so-called "barriers". And yes,
>> on the power outage bad things are bound to happen. However, it
>> is up to bad luck.
> Hm. Write barriers are not supported? `man mount | grep barrier` yields
> many results... or are they different barriers?
>
> --
> Ivan Shapovalov / intelfx /
>
>> The attached patch removes the rest of block barriers support in
>> reiser4. So, now we honestly wait for IO completion of wandered
>> blocks (overwrite set) before submitting a journal header (journal
>> footer).
>>
>> Not sure if it will address your problem though. Also, data
>> corruption
>> after rw-mounting of checked (rebuild-fs) partition is still a
>> concern.
>>
>> Thanks,
>> Edward.