> Ух, да, если метеорит попадет в твой сервак - RAID тебе от этого никак не поможет. Потому что масштаб проблемы превышает корректирующие способности схемы.А если сервак поставить в бузину на огороде?
Там контекст -- Лео Великолепный сделал очередную оптимизацию (выпуск "systemd 219 с поддержкой расширенных возможностей Btrfs") :
> > > On 2015-02-16 23:59, Lennart Poettering wrote:
> > > > * journald now sets the special FS_NOCOW file flag for its
> > > > [...] It degrades btrfs' data integrity guarantees for the files to the same levels as for
> > > > ext3/ext4 however. This should be OK though as journald does its own data integrity checks and all its objects are
Его спрашивают:
>> Zbigniew Jędrzejewski-Szmek:
>> 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?
Т.е. "btfs проверки целостности позовляют прозрачно восстановить данные, если есть копия, позволяет ли journald провернуть такое же"
На что следует ответ:
> [Lennart] 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...
И тут номерному анониму становится резко непонятно:
https://btrfs.wiki.kernel.org/index.php/FAQ#What_checksum_fu...
> Currently Btrfs uses crc32c for data and metadata.
то ли вика БТРФа не отображает реальность, то ли номерной аноним что-то фатально не понимает, то ли Лео Великолепный поступил в лучших традициях опеннета -- с умным видом <эт самое>. Что в исполнении главного/ системного разработчика повсюду встраиваемой компоненты, как минимум стремновато.
