Возможно ли, что только один бит переключается, поэтому мой файл показывает мне букву «Q» вместо «S»


22

В нашем приложении мы используем Hibernate и PostgreSQL для хранения данных. В одной из наших таблиц базы данных у нас есть столбец дискриминатора, который говорит, например, «TIPPSPIEL». Это фиксированная строка и не может быть изменена любым пользователем.

Внезапно у нас появилась одна запись в этой огромной таблице, в которой вместо TIPPSPIEL вместо «TIPPSPIEL» было указано «TIPPQPIEL». Мы понятия не имеем, как это может произойти.

Возможно ли каким-либо образом, что наш жесткий диск переключается на один бит, поэтому наша буква «S» больше не кодируется как «1010001», а внезапно становится «Q» на жестком диске с одним битом, переключенным следующим образом: 1010011?

Я не эксперт по физике жестких дисков, но, полагаю, в ОС или на диске есть контрольные суммы и другие вещи, которые гарантируют, что этого не произойдет.

Возможно ли переключение всего на один бит, чтобы мой файл показывал мне букву «Q» вместо «S»?

ОБНОВЛЕНИЕ: Мы сделали дальнейший анализ. Наша ведомая база данных получает свои записи WAL от мастера (функция PostgreSQL). Что бы ни было: наш подчиненный сервер должен быть синхронизирован. Но раб не был синхронизирован относительно этого конкретного ряда. Мы могли видеть, что это произошло несколько дней назад без какого-либо взаимодействия пользователя с этой конкретной записью. Так что это ДОЛЖНО быть немного переворачиваться. страшно!


Я предпочел бы предположить, что это произошло из-за неисправной памяти. У вас еще есть журнал, когда этот столбец был написан?
ot--

1
Это маловероятно, но возможно, биты в пути переворачиваются с высокой степенью регулярности, см. «Битсквоттинг»
Sirch

Ответы:


10

Очень редко мы видим действительно интересный вопрос на этом сайте, поэтому прежде всего спасибо.

Я думаю, что то, что вы видите, действительно является однобитовой ошибкой, удивительно, что вы можете заметить ее, если честно, но вы правы, предполагая, что второй младший бит был переключен (если вы используете ASCII так или иначе).

Что касается контрольных сумм и т. Д., Когда они были записаны на диск, скорее всего, они будут проверены как нормальные - я уверен, что эта проблема возникла впоследствии из-за простой ошибки магнитной утечки. Но вы правы, есть проверки кодировки, они отличаются от производителя, но, возможно, где-то есть ошибка, говорящая «это выглядит немного странно» - но какой вариант у вашей цепочки ввода-вывода есть? отказать тебе весь блок? Я собираюсь предположить, что это один не-RAID-диск, так как на RAID-дисках, как правило, доступно больше опций при обнаружении ошибок.

Это странно, хотя такого рода вещи, вероятно, случались несколько раз в секунду по всему миру.


1
Вы правы, в данном случае это была не-Raid настройка диска. как показывает мой дальнейший анализ, это произошло спустя много времени после записи.
Janning

1
Если мне 20 лет, как сисадмину, я видел 3 случая одного броска. Только один из них может быть доказан на 100%. Два других предположительно были перевернутыми битами, мы не могли сказать наверняка. (Бит мог перевернуться в памяти после прочтения файла. К тому времени, когда мы заметили несоответствие, исходный файл больше не был доступен или был затронут. Я вполне уверен, что это происходит чаще, чем каждый думает, но это редко замечается и обычно не доказуемо, если это замечено.
Тонни

1
Сбой чтения всего блока - это именно то, что делают накопители, когда они получают неисправимую ошибку. Невозможно сделать только один бит в части пользовательских данных сектора, и остаться незамеченным. Бит, должно быть, был перевернут, когда он был записан на диск.
psusi

Следует ли сделать этот вопрос каноническим?
Охотник на оленей

@psusi Не исключено, так как вам нужно достаточно бит-флипов в секторе, чтобы заставить ECC работать правильно. Маловероятно, но возможно, и производители дисков указывают достаточно высокий уровень ошибок, который вы действительно должны ожидать увидеть. Я слышал слухи, что люди ZFS видят их (из-за контрольных сумм данных уровня ZFS) ...
derobert
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.