[systemd-devel] [ANNOUNCE] systemd 219

[Joonas Sarajärvi]

2015-02-18 12:19 GMT+02:00 Lennart Poettering <lennart at poettering.net>:
> On Wed, 18.02.15 12:13, Joonas Sarajärvi (muep at iki.fi) wrote:
>
>> 2015-02-18 12:07 GMT+02:00 Lennart Poettering <lennart at poettering.net>:
>> > On Wed, 18.02.15 06:22, Andrei Borzenkov (arvidjaar at 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