Нужна продвинутая программа для тестирования чтения/записи на девайс

[Bizdelnick]

Дано: некая флешка, на которой badblocks ошибок не находит. При посредстве dd данные записываются корректно. А вот когда запись идёт через файловую систему (любую) - начинаются глюки. Причём при записи одного и того же набора файлов ошибка возникает всегда в одном и том же месте.
Напрашивается вывод, что ошибка происходит только при нелинейной записи. Есть ли в природе программа, пригодная для выявления таких ошибок?
А может, чем чёрт не шутит, кто-нибудь сталкивался с подобным?

[sciko]

Дано: некая флешка, на которой badblocks ошибок не находит.

Я так понимаю флешка проверяется без ключа -w? Рекомендую попробовать с ним. Напоминаю, что этот параметр приводит к уничтожению информации на устройстве к которому используется badblock!

При посредстве dd данные записываются корректно.

Это ни о чём не говорит. Это же флешка!
Обычно флешки проверяют так:
1) Забивают нулями
dd if=/dev/zero of=/dev/sdX
2) Проверяют контрольную сумму
head -c N /dev/sdX | md5sum
head -c N /dev/zero | md5sum
Здесь N -- числу байт, записанных на флешку при помощи dd.

Причём при записи одного и того же набора файлов ошибка возникает всегда в одном и том же месте.

Как вариант: шалит контроллер или флешка банально плохо воткнулась и контакт только частичный.

[SLEDopit]

Как вариант: шалит контроллер или флешка банально плохо воткнулась и контакт только частичный.

В одном и том же месте?
У меня был внешний винт с шальным контроллером (по usb подключалось оно). Там запись всегда прерывалась в случайный момент. Иногда удавалось 10G записать, а иногда и 100М не успевал.

[Bizdelnick]

Я так понимаю флешка проверяется без ключа -w? Рекомендую попробовать с ним.

Проверял с -n. Сейчас запустил проверку с -w - на первых трёх проходах ошибок не нашлось. Upd. Проверка закончилась, ошибок нет.

Это ни о чём не говорит. Это же флешка!
Обычно флешки проверяют так:
1) Забивают нулями
dd if=/dev/zero of=/dev/sdX
2) Проверяют контрольную сумму
head -c N /dev/sdX | md5sum
head -c N /dev/zero | md5sum
Здесь N -- числу байт, записанных на флешку при помощи dd.

А какая, собственно, разница, нули я залил или не нули? Контрольная сумма совпала - это главное.
Да, если непонятно: сообщений об ошибке я не получаю, просто неправильно записывается файл (или метаданные файловой системы).

Как вариант: шалит контроллер или флешка банально плохо воткнулась и контакт только частичный.

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

[drBatty]

А какая, собственно, разница, нули я залил или не нули?

а большая.

Кстати говоря, битые флешки бьются именно на определённом паттерне. Это на самом деле объяснимо, но объяснение получится слишком сложным. Если в двух словах, то суть в том, что для применяемых алгоритмов кодирования данных, есть "удобные" комбинации, и есть "неудобные". На "неудобных" вероятность ошибки намного больше. Потому, если флешка помирает, то она обычно один какой-то определённый файл не может сохранить, с какой-то хитрой комбинацией битов внутри.

Это похоже на расчёску, в которой рандомно не хватает 4/5 зубьев -- вроде как дырки везде большие, но есть одно место, где два зубца случайно оказались по соседству. Там и цепляет...

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

Думаю, они в курсе. Ну должны быть. Это такой баг by design. "Плохие" комбинации довольно длинные, и довольно редкие, просто запакуйте проблемный файл gzip -1 (но не 0). Проблема исчезнет. Ну а вообще говоря, эту флешку пора выкидывать.

ЗЫЖ возможно, у вас и другая проблема, не эта.

head -c N /dev/zero | md5sum

facepalm...

[Bizdelnick]

Кстати говоря, битые флешки бьются именно на определённом паттерне. Это на самом деле объяснимо, но объяснение получится слишком сложным. Если в двух словах, то суть в том, что для применяемых алгоритмов кодирования данных, есть "удобные" комбинации, и есть "неудобные". На "неудобных" вероятность ошибки намного больше. Потому, если флешка помирает, то она обычно один какой-то определённый файл не может сохранить, с какой-то хитрой комбинацией битов внутри.

Так, вот это интересно. Получается, что на других флешках из той же партии баг может не воспроизвестись? И можно какую-нибудь ссылку, где про это написано подробнее?

"Плохие" комбинации довольно длинные, и довольно редкие, просто запакуйте проблемный файл gzip -1 (но не 0). Проблема исчезнет.

Увы, всё не так просто. Как я уже писал, ошибка иногда появляется не в файле, а в самой файловой системе. Один из файлов, на котором проявляется баг - многогигабайтный bzip2-архив...

Ну а вообще говоря, эту флешку пора выкидывать.

Флешка новая. Условия, увы, таковы, что выкидывать нельзя.

[drBatty]

Так, вот это интересно. Получается, что на других флешках из той же партии баг может не воспроизвестись?

естественно нет. С математической т.з. RS-коды гарантируют только _минимальное_ расстояние между кодами. Построить код такой, что-бы минимальное расстояние всегда было минимальным невозможно. Потому это расстояние обычно несколько больше минимального, но для некоторых комбинаций входных кодов оно действительно минимально. Т.о. RS код может _гарантировано_ исправлять t ошибок данных в _любом_ случае, однако, в большинстве случаев, RS-код исправляет и t+x ошибок. Причём это x сильно зависит от входных данных(его(x) значение равно 0 или 1. Причём вероятность 1 сильно больше).

Таким образом, к моменту, когда RS-код уже НЕ может справится с ошибками, он не справляется вовсе не для любых данных, а только для вполне детерминированных.

дело в том, что t ошибок сдвигает код на t битов влево или вправо. И если это такой код, для которого следующий точно равен t, то ошибка будет обнаружена, но не будет исправлена. Если-же ближайший код будет расположен на расстоянии t+1, то ошибка будет исправлена. AFAIK размер кодов очень велик (тысячи бит), и расстояние между ними почти всегда t+1 или даже больше, потому в большинстве случаев ошибки находятся и исправляются. Однако, если ошибок t (причём t очень малое и равно 1 или 2 или 3), и если код "плохой", то в этом коде почти наверняка будет ошибка, из-за огромного размера этого кода (в тысячи бит, которые разбросаны по всему носителю).

С одной стороны вероятность "плохих" кодов довольно мала, но с другой стороны, эти "плохие" коды прямо зависят от входных данных. А значит, если вам не повезло, и какой-то файл приводит к созданию "плохого" кода, тогда этот файл практически гарантированно будет записан с ошибкой. И даже если ошибка не проявилась сейчас, она проявится на след. чтении (после перемонтирования), потому-что хотя-бы одна ячейка(внутри кода) прочитается неправильно.

Увы, всё не так просто. Как я уже писал, ошибка иногда появляется не в файле, а в самой файловой системе. Один из файлов, на котором проявляется баг - многогигабайтный bzip2-архив...

ничего не понял... Ну сожмите этот архив, в чём проблема? Цель этого сжатия -- ИЗМЕНИТЬ значения байт, так, что-бы "плохой" RS-код не появился.

Флешка новая. Условия, увы, таковы, что выкидывать нельзя.

ну и что, что "новая"? Какой-то остров "плывёт", и заряды оттуда вытекают. Во время контроля качества тоже вытекали, но чуть меньше порога, и контроль был пройден, теперь вытекают чуть сильнее порога, и данные хранить на этом носителе уже нельзя. RS-коды конечно спасают ситуацию, но это же не магия! RS-код может исправить не более t ошибок, если ошибок больше -- извините. Чудес не бывает. Некоторые коды НЕ исправляются. Скажите спасибо, что эти "плохие" коды достаточно редкие(как раз за счёт того, что они довольно большие. С другой стороны, если уж "плохой" код появился, то он уж точно не прочитается, когда математическое ожидание t ошибок на 1 код станет равным 1).

[drBatty]

PS: надо понимать, что RS коды НЕ увеличивают общую надёжность: Просто без них, вероятность прочитать файл без ошибок, линейно уменьшается за всё время эксплуатации. Т.е. от некого x0, до другого x1. Если посчитать определённый интеграл от x0 до x1, мы получим некое S. С RS-кодами, это S НЕ изменится. Но вот форма кривой изменится -- она станет сильно нелинейной, т.е. первое время вероятность сбоя не будет уменьшаться, но в конце эксплуатации вероятность сбоя ВНЕЗАПНО подскочит до 1. Как только математическое ожидание t ошибок на 1 код превысит 1.

Но не для всех кодов, а только для некоторых "плохих".

Естественно, конкретное время превышение этого порога неизвестно, только лишь статистически. Для 95% флешек оно больше гарантийного срока (а может и не для 95%. Это уже маркетологи решают, какой должен быть процент возврата. При разработке эта цифра задаётся в ТЗ. 95% берётся в "обычном" случае, это такой компромисс.)

Для конкретной флешки, момент превышения порога может быть любым...

И да, насколько я знаю, это всё никак не диагностируется. Не тот это девайс...

[Bizdelnick]

Ну сожмите этот архив, в чём проблема?

Архив обрабатывается скриптом. Переделывать скрипт под глюк конкретной флешки бессмысленно. Да и места для записи пережатого архива нет.
Собственно, на данный момент моя задача - понять, что же происходит, и доложиться об этом заказчику. Что делать дальше - отдельный вопрос.

[drBatty]

Архив обрабатывается скриптом. Переделывать скрипт под глюк конкретной флешки бессмысленно. Да и места для записи пережатого архива нет.

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

Да, для этот рецепт подойдёт лишь если НАДО сохранить файл, а флешка всего одна. Вот такая вот.

Если вам часто приходится переносить данные на флешках, то рекомендую использовать вот это: http://en.wikipedia.org/wiki/Parchive У меня где-то скрипт был, который режет файл на куски, и его сохраняет (а потом восстанавливает). Как раз для такого случая. Ну и для случая, когда данные важны, и при этом нет ни времени, ни места для их дублирования.

Могу вам заранее сказать, что вероятность чтения файла с флешки вовсе не равна 146%. Причём файл можно потерять даже за 10 минут хранения на новой флешке(а также он может там лежать годами, без порчи).

Собственно, на данный момент моя задача - понять, что же происходит

флешку менять надо. Очевидно жеж... Так и доложите.

[Bizdelnick]

Если вам часто приходится переносить данные на флешках, то рекомендую использовать вот это: http://en.wikipedia.org/wiki/Parchive

Занятная штука, но, увы, в данном конкретном случае неприменима.