| vasek |
|
|
Темы:
47
Сообщения:
11742
Участник с: 17 февраля 2013
|
Еще один эксперимент ... в части разного количества блоков, отображаюжих файл. 1. Имеем файл ~/test (занимает 8 блоков по 512 байт) cat ~/test 2. В файле ~/test оставляем только 1 блок (512 байт), остальные пустые блоки отрезаем dd bs=512 count=1 if=/dev/sda of=~/test1 skip=292503469 cat ~/test1 Смотрим sha256sum и … видим, что он не совпадает с первоначальным sha256sum ~/test1 Выводы делать не буду, возможно что где то что то и напортачил (проверять не хочется).
Ошибки не исчезают с опытом - они просто умнеют
|
| jamakasi |
|
|
Темы:
1
Сообщения:
16
Участник с: 20 декабря 2018
|
vasekВсе верно они и должны отличаться. Физический размер файла изменился т.к. ты отрезал нули. Соответсвенно и sha не совпадет т.к. она подсчитывается именно по содержимому и его количеству. |
| vasek |
|
|
Темы:
47
Сообщения:
11742
Участник с: 17 февраля 2013
|
jamakasiНе все так просто, хоть и обрезал, но объем файла не уменьшился, а увеличился, НО, главное, изменились и атрибуты файла stat ~/test stat ~/test1 А потому и затрудняюсь сказать, что повлияло на изменение sha256sum - или оба отклонения или только одно. Экспериментируй дальше. EDIT 1 - для полноты картинки нужно было обрезать по другому - оставить не 512 байт, а 14, то есть сохранить прежний размер
Ошибки не исчезают с опытом - они просто умнеют
|
| vasek |
|
|
Темы:
47
Сообщения:
11742
Участник с: 17 февраля 2013
|
Вообщем, просто изменение Еще провел маленький экспериментик - изменил stat ~/test
Ошибки не исчезают с опытом - они просто умнеют
|
| jamakasi |
|
|
Темы:
1
Сообщения:
16
Участник с: 20 декабря 2018
|
vasek, кажись у меня потихоньку складывается впечатление что произошло глядя на твой эксперемент. Не трогай пока свой /home/vasek/test пока не прочтешь мысль ниже. Я не знаю как и через что ты создал файл но складывается следующее впечатление. Вариант 1. При сохранении файла программа которой ты сейвил файл "оптимизировала" его размеры увидев что в нем всего 14 байт и 3584 байта нулей, т.е. она их тупо откинула физически сохранив только 14 байт. Это можно проверить через hdparm --fibmap ~/test глянув и подсчитав begin_LBA end_LBA параметры. Вариант 2. Программа которой ты сохранял файл не причем, сюда вмешались алгоритмы ФС которые могли сделать следующее. При сохранении ФС увидела что файлик такой красивый и идеально выровнен на 8 блоков по 512 байт каждый, подумала и по встроенным алгоритмам оптимизации физически сохранила только 14 байт а дальше в служебной мета информации пометила что столько то блоков зарезервирована. Соответственно при любом чтении этого файла недостающие нули сгенерируются из /dev/zero чтобы не крихтеть жестким диском. Соответсвенно при чтении реальный размер файла становился 4096 т.е. добивался нулями а значит sha256 считал именно столько байт. Тут ниже распишу отдельно как это проверить можно. Вариант 3. Если вариант 2 справедлив то вероятно dd bs=512 count=1 if=/dev/sda of=~/test1 skip=292503469 конкретно OF= работает несколько по иному и чхать хотел на некоторые алгоритмы ФС. Т.е. он тупо взял 512 байт с такого то смещения и физически их вытащил. дальше он заставил ФС физически сохранить ровно 512 байт не включая ее оптимизации чтобы она не метила нулевые байты чтобы их потом выдать из /dev/zero. Т.е. он сохранил и убедился что они действительно физически сохранены. А теперь как это проверить. -Предварительно считаешь sha256sum ~/test и смотришь stat ~/test. Копируешь через cp файл и сравниваешь снова с копией. Теоретически если ты сейчас через dd т.е. минуя ФС запишешь по смещению файла + ну например 14 байт что угодно. Т.е. тебе надо будет отсчитать как то так на основе твоих данных , если читал dd bs=512 count=1 if=/dev/sda of=~/test1 skip=292503469 , значит будет типа dd count=1 if=некий_файл_пара_байт of=/dev/sda skip=292503469*512+14 Теперь считаешь sha256sum ~/test и смотришь stat ~/test . Что было и что стало относительно оригинала и копии. По идее все должно совпадать т.к. фс незнает о том что там что то есть и все также будет выдавать /dev/zero. Теперь пробуешь скопировать файл через dd bs=512 count=1 if=/dev/sda of=~/test1 skip=292503469 .Теперь сравниваешь все файлы с ним. Теперь sha256 не совпадет как и размер файла. Копируешь этот файл через cp и смотришь сработала ли оптимизация ФС и стал ли файл весить14+2 байта. Если нет то попробуй открыть ~/test1 программой который создавал и сохранял ~/test а затем сохранить как ~/test2 . Снова смотришь sha256 и размеры. Теоретически снова сработает оптимизация ФС. Надеюсь донес мысль. Если выше написанное подтвердится то это дает гарантию что первоначальная проблема может возникать если ФС надеется что там то нули должны быть физически но если это не так и к примеру алгоритм который подсовывает /dev/zero вместо прямого чтения не включается в силу причин (высокая нагрузка на память\цпу\что то) то может произойти физическое чтений и вот тут то окажется что там могли быть не нули и они попадут в такие ровные блоки как случилось у меня. Т.е. в те самые ровные блоки пустоты по 512 байт окажутся не с пустотой а с кашей. |
| vasek |
|
|
Темы:
47
Сообщения:
11742
Участник с: 17 февраля 2013
|
Файлы я уже удалил, в принципе то и создать их по новой не проблема, но нет желания экспериментировать дальше. Вообщем то все ясно. Файл ~/test1, который получился при обрезании, получился заданным размером 512 байт - это такая была команда dd - выделить на диске с заданного offset 512 байт и сохранить результат в отдельный файл. В принципе hexdump это сразу и показал hexdump -C ~/test1 Сравни с этим hexdump -C ~/test Это же показывает и stat. Разные размеры файлов, значит и разные значения sha256sum. Предположу, что у тебя причина была тоже в разных размерах файлов (как я понял у тебя в разных системах еще и разные блоки - это как то и сказалось. Нужно смотреть). Можешь все проверить по-новой на реальных файлах - только проверяй размеры hexdump или stat. Если значения sha256sum будут не совпадать, а размеры файлов будут одинаковы, то тогда придется проверять файла по байтово. EDIT 1 - Насчет 4096 - размер файла (фактический) может быть и 10 байт и 100 байт и 1000 байт, но система оперирует страницами размером 4K (4096), столько и было выделено данному файлу на диске ... а я с диска считал 512 байт, а не 14 байт. EDIT 2 - считал 512 байт вместо 14 просто по привычке, как делаю при восстановлении файлов - считываю блоками, важна информация и не думаешь о разных нюансах, а потому сразу и не сообразил.
Ошибки не исчезают с опытом - они просто умнеют
|
| jamakasi |
|
|
Темы:
1
Сообщения:
16
Участник с: 20 декабря 2018
|
vasekЖаль, Шанс что совпадет то что получится создать файл который блоками ровненько и последовательно по диску зайдет, не так много. |
| vasek |
|
|
Темы:
47
Сообщения:
11742
Участник с: 17 февраля 2013
|
jamakasiВсе должно совпасть, работать с байтами удобно и понятно, а потому проблем не вижу. Привожу результаты повтора 1. Создание файла ~/test stat ~/test 2. Получение файла ~/test1 sudo dd bs=512 count=1 if=/dev/sda of=~/test1 skip=292510373 stat ~/test1 3. А вот сейчас из файла ~/test1 получим исходный файл ~/test, но только назовем его ~/test1-1 ... то есть скопируем из ~/test1 только 14 байт dd if=~/test1 of=~/test1-1 bs=14 count=1 stat ~/test1-1 и снова видим полное совпадение с выводом для первоначального файла ~/test Что еще раз подтверждает, что никакого бага нет, а просто имеется не совпадение файлов или по размеру или по содержимому.
Ошибки не исчезают с опытом - они просто умнеют
|
| anode |
|
|
Темы:
8
Сообщения:
1019
Участник с: 30 августа 2011
|
"Горе от ума". Спасибо. От души насмешили. Некоторые выражения достойны стать мемами. |
| jamakasi |
|
|
Темы:
1
Сообщения:
16
Участник с: 20 декабря 2018
|
anodeРаз насмешили то посвяти нас нищих и безбожный как в моем первоначальном случае в пустоты данных попал мусор? |