2015-02-18 12:19 GMT+02:00 Lennart Poettering lenn...@poettering.net:
On Wed, 18.02.15 12:13, Joonas Sarajärvi (m...@iki.fi) wrote:
2015-02-18 12:07 GMT+02:00 Lennart Poettering lenn...@poettering.net:
On Wed, 18.02.15 06:22, Andrei Borzenkov (arvidj...@gmail.com) wrote:
btrfs checksumming theoretically allows you to transparently recover
after media corruption if filesystem has redundancy (more than one copy
of data). Journald checksum will probably detect corruption, but can it
repair it?
No it cannot.
But btrfs checksumming cannot fix things for you either if you lose
non-trivial amounts of data. It might be able to fix a few bits of
errors, but not non-trivial amounts. I mean, that's a simple property
of error correction codes: the more you want to be able to correct the
longer must your checksum be. Neither btrfs' nor journald's are
substantial enough to correct even a sector...
Lennart
My impression is that btrfs can fix the corruption in cases where a
e.g. a RAID1 of btrfs is used.
FS_NOCOW does no effect btrfs raid settings. If you want this kind of
data redundancy then it will continue to be available even though we
set FS_NOCOW now.
Thank you for the quick response.
Do you mean that btrfs scrub will be able to detect which of the
copies is correct, if one of the copies of a file flagged with
FS_NOCOW gets changed due to disk corruption? My impression is that
FS_NOCOW would result in the redundant copies of file data not having
checksums that'd be correctly maintained. So btrfs scrub could
possibly detect that the copies differ, but it would not be able to
decide which one to discard.
AFAIK btrfs would normally able to do this, write a new copy of the
intact file data and discard the corrupt one.
-Joonas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
