Баг или фича?

Арчевод рекомендовал тут помощи поискать поэтому вот.

Короч немного предыстории. Вчера переносил систему на новый(старый ssd). Все перенес но внезапно некоторые(буквально десяток) утилит перестало пахать выкидывая странные ошибки. Решил сранить sha256 на новом и старом накопителях. Вылезло хоть и немного но буквально уже пара десятков файлов которые отличаются, файлы как собственно эльфы и либы так и банальные текстовые и картинки. При внимательном рассмотрении выяснилось что различие в файлах были абсолютно всегда блоками ровно по 512 байт, число таких блоков было разным но! всегда эти блоки попадали если в файле были нулевые данные.

Долго думал, курил.
Так вот что произошло, пока предварительно т.к. на 100% повторить не придумал как.
Дано:
ssd с которым я проделал следующее в последовательности:
1) Полное форматирование. Т.е. физически все забил нулями
2) С помощью victoria сделал тесты чтения, проверки и ЗАПИСИ. Тут ключевой момент в записи т.к. виктория физически в каждый блок из 512 байт в начале вписывает следующее LBA "номер" "Дата" "время" дальше нули до конца блока.
3) Создал разметку диска MBR
4) Создал раздел в ext4

Теперь более привычные вещи:
1) С помощью rsync с ключами -avx скопировал файлы. В моем случае / раздел
2) Замечаю что некоторые програмки\библиотеки отвалились со странными багами
3) Сравниваю sha256 проблемных и некоторых НЕ проблемных файлов и вижу что они отличаются
4) Чешу затылок в шоке как так то б*еа?!?!
5) с помощью обычного cp копирую вместо битых файлов нормальные
6) Проверяю через sha256, все ок.
7) Задумчиво курю, пью пиво, думаю что делать. Не сплю пол ночи и рожаю схему которую сейчас пишу.

А теперь теория почему это произошло, частично некоторые моменты я смог повторить:
1) 512 байт на блок это исторический момент и ОЧЕНЬ МНОГИЙ а точнее почти ВЕСЬ софт это учитывает в своей работе.
2) ФС естественно это тоже учитывают и могут делать свои оптимизации на этот счет при работе с файлами и каталогами
3) В битых файлах абсолютно всегда несовпадали именно блоки ровно по 512 байт.
4) В этих несовпадающих блоках я видел именно то что там оставила виктория а именно LBA "номер" "Дата" "время"
5) Так сходится что данные файла а именно пустота\нули попадают четко в блоки по 512 байт
6) Какаято сволочь, по видимому чисто для оптимизации и ускорения при копировании если видит что следующий блок данных с нулями\пустой просто его не копирует а пропускает. Соответсвенно эта сволочь наивно полагает что физически на диске в этом месте тоже нули\пустота но это может быть не так.
7) На выходе в итоговый скопированный файл в местах в которых физически совпало что в блоке должны быть нули оказываются старые данные и естесвенно sha не совпадет.
8) Для большинства файлов такой замес каши внутри вместо пустот некритичен т.к. чаще всего структурно данные пронумерованы где и что в нем лежит и такие пустоты игнорируются. Но в некоторых случаях файл может проверяться алгоритмами что он должен быть такой и пустотой в таком месте. Так же некоторые форматы всегда хранят данные не структурировано а скажем читаются пока не встретятся нули. Бинарники могут себя проверять в т.ч. цифровые подписи и подобное и естесвенно ничего не совпадет. Жесть полная
9) Я в ахуе от произошедшего, теперь думаю как повторить это лабораторно и если это поведение повторяется всегда в т.ч. на другом железе\софте то это БАГ причем ахринеть какой критичный!!!

Переписывать все грамотно очень лень и особо некогда пока что. Поэтому почти весь текст выше копипаста моих фраз из переписки. Доп данные могу приложить по версиям софта и т.д. Единственное что тупанул это не скопировал для дальнейшего исследования "битые" файлы и в данный момент вертал все взад а теперь этот ssd выступает лабораторной крысой надо которой думаю и пробую повторить последовательность.
Пинайте.
С таким не сталкивался, но мне кажется подвох в этом.
jamakasi
Тут ключевой момент в записи т.к. виктория физически в каждый блок из 512 байт в начале вписывает следующее LBA "номер" "Дата" "время" дальше нули до конца блока.
Идея такая. Виктория передала контроллеру ssd информацию, что блоки пустые, при этом насрав в них.

ФС какая кстати?
Lupus pilum mutat, non mentem.
jim945
С таким не сталкивался, но мне кажется подвох в этом.
jamakasi
Тут ключевой момент в записи т.к. виктория физически в каждый блок из 512 байт в начале вписывает следующее LBA "номер" "Дата" "время" дальше нули до конца блока.
Идея такая. Виктория передала контроллеру ssd информацию, что блоки пустые, при этом насрав в них.

ФС какая кстати?
ФС в обоих случаях ext4.
ssd с которым я проделал следующее в последовательности:
1) Полное форматирование. Т.е. физически все забил нулями
2) С помощью victoria сделал тесты чтения, проверки и ЗАПИСИ. Тут ключевой момент в записи т.к. виктория физически в каждый блок из 512 байт в начале вписывает следующее LBA "номер" "Дата" "время" дальше нули до конца блока.
Но зачем?!!
Достаточно было просто отформатировать, у SSD своя специфика, и даже после быстрого форматирования восстановить данные будет практически невозможно.
Для клонирования диска есть православная dd, где можно указать bs - размер блока, например:
dd if=/dev/sda bs=8M conv=sync,noerror | gzip -c > /mnt/backup/sda.img
Либо использовать спец. дистрибутивы, типа https://clonezilla (аналог Acronis для линуксов). Но там под капотом та же dd
52th
ssd с которым я проделал следующее в последовательности:
1) Полное форматирование. Т.е. физически все забил нулями
2) С помощью victoria сделал тесты чтения, проверки и ЗАПИСИ. Тут ключевой момент в записи т.к. виктория физически в каждый блок из 512 байт в начале вписывает следующее LBA "номер" "Дата" "время" дальше нули до конца блока.
Но зачем?!!
Достаточно было просто отформатировать, у SSD своя специфика, и даже после быстрого форматирования восстановить данные будет практически невозможно.
Для клонирования диска есть православная dd, где можно указать bs - размер блока, например:
dd if=/dev/sda bs=8M conv=sync,noerror | gzip -c > /mnt/backup/sda.img
Либо использовать спец. дистрибутивы, типа https://clonezilla (аналог Acronis для линуксов). Но там под капотом та же dd
Виктория была задействована чтобы убедиться в исправности ssd. Если его понасиловать таким образом то гарантировано и адекватно обновится состояние смарта.
Клонировать через dd был не вариант т.к. количество и размеры разделов полностью разные.

Всякие акронисы и клонзилы? Зачем такие сложности ? Кроме того зачастую неадекватные по работе чаще всего. Я быстрее размечу веник, копирну все через rsync, поправлю guid в /etc/fstab и grub.cfg, скажу grub-instal. Вот и все, все быстро и максимально под контролем.
Виктория была задействована чтобы убедиться в исправности ssd.
Чем smartctl не угодил?
sudo smartctl -i -a /dev/sda
jamakasi
С помощью rsync с ключами -avx скопировал файлы. В моем случае / раздел
оставлю это здесь
52th
Виктория была задействована чтобы убедиться в исправности ssd.
Чем smartctl не угодил?
sudo smartctl -i -a /dev/sda
Еще раз сообщаю, современные ssd через чур хитрожопые и смарт ведут крайне лениво. Для того чтобы контроллер ssd провел НАСТОЯЩУЮ проверку состояний надо принудительно провести полное чтение\запись всего диска от и до. Классический прием "попросить" smartctl -i -a в большинстве не даст адекватную картинку того что на самом деле, даст только после физического прогона, вот уже потом smartctl -i -a можно хоть както верить.
red
jamakasi
С помощью rsync с ключами -avx скопировал файлы. В моем случае / раздел
оставлю это здесь
И собственно что там особенного опции aAXv и мои использованные avx? Я вот что то люто сомневаюсь что вы хоть раз использовали xattr, с acl атрибутами никогда не игрался т.к. хватает того все работает. Да и вообще наличие\отсутствие опции AX абсолютно никак не влияет на то что в конечном счетесами данные в файле отличались а атрибуты это немного отдельная тема как и ее хранение.
jamakasi
52th
Виктория была задействована чтобы убедиться в исправности ssd.
Чем smartctl не угодил?
sudo smartctl -i -a /dev/sda
Еще раз сообщаю, современные ssd через чур хитрожопые и смарт ведут крайне лениво. Для того чтобы контроллер ssd провел НАСТОЯЩУЮ проверку состояний надо принудительно провести полное чтение\запись всего диска от и до. Классический прием "попросить" smartctl -i -a в большинстве не даст адекватную картинку того что на самом деле, даст только после физического прогона, вот уже потом smartctl -i -a можно хоть както верить.
red
jamakasi
С помощью rsync с ключами -avx скопировал файлы. В моем случае / раздел
оставлю это здесь
И собственно что там особенного опции aAXv и мои использованные avx? Я вот что то люто сомневаюсь что вы хоть раз использовали xattr, с acl атрибутами никогда не игрался т.к. хватает того все работает. Да и вообще наличие\отсутствие опции AX абсолютно никак не влияет на то что в конечном счете сами данные в файле отличались а атрибуты это немного отдельная тема как и ее хранение.
Для того чтобы контроллер ssd провел НАСТОЯЩУЮ проверку состояний надо принудительно провести полное чтение\запись всего диска от и до
Возможно, спорить не буду.
Просто я Викой прогоняю тест поверхности HDD, на предмет битых блоков (бэды). Но в SSD нет блоков, как и нет физического доступа к диску (он есть только у контроллера). Если есть возможность, скиньте ссылочку, где расписана данная методология проверки SSD. Я почитаю на досуге, самому интересно.
 
Зарегистрироваться или войдите чтобы оставить сообщение.