Баг или фича?

jamakasi
теперь этот ssd выступает лабораторной крысой надо которой думаю и пробую повторить последовательность.
ну и как удачно? повторил с тем же результатом?
Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874
nafanja
jamakasi
теперь этот ssd выступает лабораторной крысой надо которой думаю и пробую повторить последовательность.
ну и как удачно? повторил с тем же результатом?
Повторить удалось но при полном воспроизведении ситуации. Т.е. лабораторно чтобы вот прям конкретный файлик нет. В целом забил уже и забыл раз народу абсолютно не интересно и главное потыкать в несвязные вещи.
Если происходят непонятные и необьяснимые вещи, изучайте системные логи. С большой вероятностью найдете там какие-нибудь ошибки IO.
При копировании файла его контрольная сумма обязана сохраняться.
Оставим в стороне всякую лирику
jamakasi
Долго думал, курил.
Чешу затылок в шоке

Исходные: при копировании файлов sha256sum некоторых не совпали, при повторном копировании всё ок, все остальное: ключи при копировании, блоки с нулями, тем более разлияия в "хвостах" блоков и т.д. и т.п. - от лукавого. Возможны всего две причины ошибки.
1. Ошибка при чтении исходного файла.
2. Ошибка при записи целевого файла.
Всё. Дальше все проделанное - от лукавого или как я назвал "горе от ума". Я за второй вариант, т.к.:
1)
jamakasi
новый(старый ssd).
2) ноль для ссд активное состояние, как раз с записью нуля и должны быть проблемы
3)повторная запись 100% произошла в другие физические ячейки, которые еще не сдохли.
Это пять:
jamakasi
Задумчиво курю, пью пиво, думаю
Как очень маловероятный вариант: плохой контакт в сата шлейфе..
Я повторюсь - просто имеется не совпадение файлов или по размеру или по содержимому - скорее всего второе, а уж как это вышло, нет смысла гадать.

EDIT 1 - хэш не подправишь, это не CRC32, который можно и подменить ...
Ошибки не исчезают с опытом - они просто умнеют
vasek
EDIT 1 - хэш не подправишь, это не CRC32, который можно и подменить …
Я дико извиняюсь, но CRC32 - это тоже хеш, по крайней мере согласно википедии.
vasek
нет смысла гадать
Вы не поняли, ТС не хочет гадать, он хочет повторить и получить точный ответ как это произошло, вместо того чтобы покрасить зелёной краской, привязать верёвочку и сделать закидушку на карася.
anode
но CRC32 - это тоже хеш
Что то вспомнилоь былое и потянуло на offtop, не обижайтесь, немного наведу лирики.

Давно не занимался этим, если быть точным, то метод CRC не совсем хэш - это метод подсчета контрольной суммы (checksum), которую добавляют к сообщению, прописывают в файле и предназначено все это для того, чтобы знать, что информацию не подменили.
Так было раньше, сейчас, наверное, это уже и не используют.
А начиналось все довольно просто - применялся простой способ подсчета контрольной суммы - подсчитывается сумма байтов и прописывается в определенной позиции этого же файла. Если текст изменили, изменится и контрольная сумма, которая не совпадет с прописанной. Это все ломалось, используя соответствующие проги, как вычислялись пароли и разрабатывались генераторы паролей.
Жизнь менялась, совершенствовалась техника защиты, но совершенствовались и проги.
В частности CRC32 - это циклический избыточный код, как бы сказать усложненный вариант подсчета контрольной суммы.
Не прав я в одном, написав CRC32 - имел ввиду обычный простой подсчет контрольной суммы.
Сейчас все строится на хэше, который не обратим, т. е. вычислить пароль, зная хэш, не возможно. Но и здесь есть нюансы - если доступен файл /etc/shadow, то мы видим хэш пароля root, на основе этого хэша можно получить новый хэш (с твоим заданным паролем) и подменить старый и зайти в систему. НО это все для изучения, технически это не нужно, так как имея физический доступ к компу, зайти в него не прооблема.
Ошибки не исчезают с опытом - они просто умнеют
anode
Оставим в стороне всякую лирику
jamakasi
Долго думал, курил.
Чешу затылок в шоке

Исходные: при копировании файлов sha256sum некоторых не совпали, при повторном копировании всё ок, все остальное: ключи при копировании, блоки с нулями, тем более разлияия в "хвостах" блоков и т.д. и т.п. - от лукавого. Возможны всего две причины ошибки.
1. Ошибка при чтении исходного файла.
2. Ошибка при записи целевого файла.
Всё. Дальше все проделанное - от лукавого или как я назвал "горе от ума". Я за второй вариант, т.к.:
1)
jamakasi
новый(старый ssd).
2) ноль для ссд активное состояние, как раз с записью нуля и должны быть проблемы
3)повторная запись 100% произошла в другие физические ячейки, которые еще не сдохли.
Это пять:
jamakasi
Задумчиво курю, пью пиво, думаю
Как очень маловероятный вариант: плохой контакт в сата шлейфе..

При чтении:
1) Тогда каким образом я читаю этот файл хоть до посинения и все ок?
2) Тогда каким образом я спокойно пишу именно в этот LBA ? Кроме того каким образом в этом LBA оказались данные от виктории?

"Горе от ума":
1) Да, все тесты на зануление, заполнение кашей, заполнением единицами проходят на ОК.
2) Проверено через dd всегда пишется именно то что подразумевалось.
3) См. п1, все синтетические тесты проходятся на ура.

"Пять":
Именно этот вариант я тоже не исключаю о чем писал на старте. Кроме того не исключаю варианты кривых версий софта\ядра\библиотек. Кривых контроллеров. Рук из жопы, Странного бага контроллера харда\ссд. Магнитной бури, приближения нибуру и т.д. . К сожалению другого ссд\хардка\железа проверить нет возможности, утащить домой это железо и проверить также нет возможности как и наоборот притащить железо из дома чтобы поэкспериментировать. Кроме того именно на работе где все это произошло чаще всего времени не так много чтобы заниматься выяснением причин и проведения следственных действий.

Нет желания предложить вариантов тестов как vasek? Ну и нафиг тогда доказывать что земля плоская и вообще вокруг мудаки необразованные, лучше промолчи или еще лучше предложи как воспроизвести это, получится я тебе лично разрешаю запостить баг от твоего имени, не баг значит я рукожоп\кривое железо\кривые руки\нибуру скоро упадет.
vasek
Что то вспомнилоь былое и потянуло на offtop, не обижайтесь, немного наведу лирики.
crc до сих пор активно используется. Как бы небыли хороши другие алгоритмы но все они гораздо медленнее. Поэтому если вопрос стоит в том что данных очень много и нужно проверять целостность то crc просто вне конкуренции.
 
Зарегистрироваться или войдите чтобы оставить сообщение.