On 04/06/2016 04:25 PM, Mathieu Belanger wrote:
Well, I did boot systemrescuecd to fsck my /dev/sda2 and mount it ro to
do the backup and I was able to get all the data back but with a bonus :
I can mount the fscked /dev/sda2 in rw on systemrescuecd, the corruption
don't come back. SystemrescueCD is based on Gentoo I think. But the one
I got got a 3.18 kernel.
Please, mount it with "no_write_barrier" option on all kernels older
than 4.5.1 (not yet released). Horrible name, of course: this should
sound like "no_block_write_barrier", or something like this, but it is
too late to fix...
Thanks,
Edward.
I did manually compile the latest tools to be
sure and a got an error because 3.18 support format40 4.0.0, not 4.0.1
but that error did not affect me.
I will do more test with that "corrupt" partition before restorating
the backup.
On Tue, 5 Apr 2016 17:43:45 +0200
Edward Shishkin <edward.shishkin@xxxxxxxxx> 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.
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
