?

Log in

No account? Create an account
   Journal    Friends    Archive    Profile    Memories
 

Случайные однобитовые ошибки (random bit flips) - morfizm


Feb. 10th, 2013 03:52 pm Случайные однобитовые ошибки (random bit flips)

Считается, что вероятность порчи данных при нормальной работе железа, настолько низка, что домашний пользователь не должен когда либо заметить это. Ошибки, при которых случайно меняется один бит, должны сопровождаться отказом (fail) соответствующих APIs в результате parity checks, так, что операция будет повторена или отменится, или комп зависнет, ... но данные будут сохранены.

Так ли это в действительности?

Я давно подозревал, что это не так, и сегодня получил тому доказательство:

V:\V\Cartoons>fc /b "V:\Video\+Animations\Бременские музыканты.avi" "V:\V\Cartoons\Бременские музыканты.avi"
Comparing files V:\VIDEO\+ANIMATIONS\Бременские музыканты.avi and V:\V\CARTOONS\БРЕМЕНСКИЕ МУЗЫКАНТЫ.AVI
04D068F5: E6 EE

6 это 0110 в двоичной системе, а E это 1110.
Т.е. мы видим результат изменения одного бита.

Файлы вроде оба открываются, но мне лениво оба внимательно пересматривать, чтобы определить, какой из них верный. Кроме того, я могу ведь и не заметить. Но в каких-то других форматах файла, такая ошибка может быть фатальной.

Как от этого защититься?
Хранить весь stuff в архивах с избыточностью и время от времени сверять с распакованной версией?
Есть ли какой-то софт, который это уже делает?

Tags: ,

16 comments - Leave a commentPrevious Entry Share Next Entry

Comments:

From:kot_begemot
Date:February 11th, 2013 01:22 am (UTC)
(Link)
Софт есть. Называется ZFS.
Он, правда, не так это делает, но делает.
From:archaicos
Date:February 11th, 2013 01:50 am (UTC)
(Link)
Низкая вероятность не гарантирует того, что событие не произойдёт прямо сейчас или в любой другой момент. :)
From:morfizm
Date:February 11th, 2013 03:47 am (UTC)
(Link)
Ты это лучше лотерее скажи, пусть я выиграю джекпот :)
From:archaicos
Date:February 11th, 2013 03:58 am (UTC)
(Link)
Так ты купи билетик. :)
From:l_sylvanas
Date:February 11th, 2013 07:25 am (UTC)
(Link)
хехе
From:_m_e_
Date:February 11th, 2013 03:17 am (UTC)
(Link)
У архивов вроде уже есть чексуммы, по крайней мере у зипа - crc32. Не шибко хороший выбор, конечно, но уже везде есть.

Приличные бэкап утилиты тоже сохраняют чексуммы.
From:morfizm
Date:February 11th, 2013 03:48 am (UTC)
(Link)
Надо же не просто detection, нужна возможность вовремя восстановить, пока предыдущая (хорошая) версия ещё из бэкапов не потёрлась.
From:_m_e_
Date:February 11th, 2013 04:13 am (UTC)
(Link)
для этого как-раз ZFS (или S3 и тому подобные)
From:morfizm
Date:February 11th, 2013 11:24 am (UTC)
(Link)
Я почитал про ZFS. По-моему, это плохо применимо к home user scenario. Там большой management/configuration overhead, и, кроме того, ошибки исправляются только при чтении, что может быть через несколько лет после их возникновения в случае домашнего архива, и за это время уже могут появиться ошибки и на избыточных хардах. Т.е. надо самому писать какой-то cron job, который будет каждый день или по какому-то расписанию всё вычитывать.

Ты уверен, что S3 корректирует ошибки, а не только детектит? Я глянул про дополнительно передаваемый md5 для детекшна, но не увидел заметок про коррекцию.
From:andrey_larin
Date:February 11th, 2013 11:53 am (UTC)
(Link)
Мне кажется просто надо HDD нормальные брать. Где такая хрень исключена.
From:_m_e_
Date:February 11th, 2013 05:24 pm (UTC)
(Link)
Мне про ZFS пел местный линуксоид :) - говорил, есть background scrubbing. Но сейчас поискал - похоже да надо скедьюлить scrub. Но по крайней мере команда вычивающая все уже написана, надо ее только в cron засунуть.

В Космосе (внутре-Бинговский аналог S3 + EC2) background scrubbing встроен как одна из базовых фич, интергрирован чтобы занимать ресурсы в моменты минимального использования и делать полную вычитку диску за пару дней. Корректировка путем убивания плохой копии - что приводит к созданию новой копии из оставшихся хороших (Космос поддерживает 3 копии). Гугл что-то намудрил с error correction вместо просто 3 копий, подробностей не знаю, но тоже все восстановит.

Амазон конечно ничего не публикует, но думаю и там без background scrubbing не могли обойтись. Хотя меня один бывший Амазоновец пытался убедить что на cron+rsync можно построить систему не менее надежную чем S3, я ему как раз про scrubbing и выбор хорошей копии из испорченных пытался объяснить, но он остался при своих мнениях.
From:andrey_larin
Date:February 11th, 2013 09:58 am (UTC)
(Link)
Мне кажется музыка\видео к такому не критичны.
Этими ошибками кстати, грешны винты green серии от WD - у них там положено на коды коррекции ошибок.
From:morfizm
Date:February 11th, 2013 11:42 am (UTC)
(Link)
Мне кажется музыка\видео к такому не критичны.

На каком основании?
В музыке/видео наверняка есть биты, которые можно поменять, чтобы было незаметно, но есть же и управляющие биты, сломав которые сломается всё или часть. Если мы говорим о вероятностях неприятных последствий, и они несколько ниже в случае музыки/видео, то это не аргумент. Раньше говорили о вероятностях таким образом, что вообще, мол, защищаться от silent errors не надо, типа, нереально, что произойдёт. А произошло.
From:andrey_larin
Date:February 11th, 2013 11:52 am (UTC)
(Link)
Недокачанные видео с торрентов где отсутствует 10% вполне себе идут, с обрывами и глюками, но идут.
From:rezkiy
Date:February 15th, 2013 08:10 am (UTC)
(Link)
my home desktop has ECC memory. Does yours?
From:morfizm
Date:February 16th, 2013 07:06 am (UTC)
(Link)
Good point. Mine does not.
Ну и, очень вероятно, что старая железяка, которая хранила эти файлы (HP MediaSmart Server) тоже не имела ECC.