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.
--
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
