1

Можно ли автоматически рассчитать контрольную сумму каждого файла, который записывается на жесткий диск? Моя ОС - это Linux. Я читал, что btrfs хранит какие-то контрольные суммы для файлов. Можно было бы сбросить эти контрольные суммы? Как насчет других файловых систем?

2 ответа2

5

С помощью BTRFS, всего пару дней назад, я отправил патч для дампа csums. Http://www.spinics.net/lists/linux-btrfs/msg51256.html вы можете скачать патч и применить его.Дайте мне знать, если у вас возникнут какие-либо проблемы.

Использование:

btrfs inspect-internal dump-csums /btrfs/50gbfile /dev/sda4
csum for /btrfs/50gbfile dumped to /btrfs/50gbfile.csumdump

Смотрите это в действии здесь

Изменить: Последний патч можно найти здесь: https://patchwork.kernel.org/patch/9696379/ с небольшим изменением климата. Он использует "btrfs inspect-internal dump-csum" вместо "dump-csums"

btrfs inspect-internal dump-csum /btrfs/filepath /dev/name
1

Btrfs, ZFS и Windows ReFS являются одними из основных предложений файловой системы, которые предлагают встроенную проверку целостности данных в качестве функции. Это достигается путем вычисления контрольной суммы во время записи и сохранения этой контрольной суммы вместе с данными. Физическое хранилище контрольной суммы обычно находится в другом месте на диске, чтобы избежать локальных ошибок, приводящих к повреждению как данных, так и контрольной суммы, а также к обнаружению неудачной или неправильно выровненной записи (когда накопитель сообщает об успешной записи, но он не "прилипал" или данные были записаны в неправильном физическом месте).

Однако эта функция работает не совсем так, как вы думаете. Короче говоря, ZFS работает на уровне блоков, а другие файловые системы спроектированы аналогичным образом. Это избавляет от необходимости перезаписывать (или пересчитывать контрольную сумму по всей совокупности) большой файл для тривиального изменения; скорее, только измененные блоки должны пересчитывать свои данные целостности. Для больших файлов, в которых часто встречаются небольшие изменения на месте, например образы дисков ВМ, это сводится к очень заметной разнице. На этом этапе фиксированные размеры блоков в основном уходят в прошлое; О других я не знаю, но ZFS использует переменный размер блока от сектора (обычно 512 или 4096 байт) до нескольких сотен килобайт до мегабайта. С файловой системой, основанной на проверке целостности данных на уровне блоков, эти куски файлов - лучшее, на что можно надеяться, чтобы иметь возможность извлекать контрольные суммы. И давайте даже не будем вдаваться в вопрос, например, о дедуплицированном хранилище данных ...

Ваш вопрос похож на Возможно ли получить доступ к контрольным суммам ZFS для сравнения файлов при сбое сервера, и, хотя ваш вопрос охватывает больше файловых систем, чем эта, я считаю, что ответ от jlp применим в любом случае:

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

Это не значит, что то, что вы ищете, не может быть достигнуто. Фактически, с тем, что доступно в Linux, можно, вероятно, собрать воедино решение, используя такие инструменты, как inotify и выбранную вами программу вычисления контрольной суммы, чтобы вычислять контрольные суммы файлов всякий раз, когда они записываются. Windows предлагает аналогичные программные интерфейсы, которые почти наверняка могут быть задействованы. Это должно быть одинаково выполнимо поверх любой файловой системы, потому что вы в основном просто подключаетесь к обычному рабочему процессу ввода-вывода, а не изменяете данные на диске какими-либо специальными средствами. (Вы должны исключить файл , который используется для хранения контрольных сумм из этого, очевидно.)

Это само по себе, однако, дает вам только половину пути. Реальная особенность файловых систем, которые выполняют проверку целостности данных, заключается не в том, что они вычисляют контрольную сумму при записи; это происходит потому, что это позволяет им автоматически и принудительно проверять контрольную сумму на чтение. Таким образом, вы можете быть уверены, что либо вернете верные данные, либо ошибку ввода-вывода; все, что не достигло совершенства, заставит компьютер громко заявить, что есть проблема с вашим хранилищем, и / или использовать избыточные данные, чтобы исправить это самостоятельно. Поскольку операционная система делает это на уровне файловой системы, единственный способ обойти это - преднамеренное чтение непосредственно с диска, полностью обходя уровень файловой системы; почти никакое программное обеспечение пользовательского пространства не делает этого. (Дефрагментаторы и средства проверки целостности файловой системы приходят на ум как две основные категории программного обеспечения, на которые есть основания. Здесь также стоит отметить, что по крайней мере для ZFS я не знаю ни одного общедоступного программного обеспечения для восстановления данных, которое может работать с пулом ZFS, которое сами инструменты ZFS по какой-либо причине не могут импортировать. У инструментов ZFS есть несколько опций, направленных на попытки восстановления не импортируемых пулов, но если они не удастся, вам, скорее всего, не повезет.)

Более практичное решение для проверки целостности файлов, если вы не хотите использовать что-то наподобие ZFS, Btrfs или ReFS или если вам действительно нужны контрольные суммы всего файла или если вам нужно обнаружить изменения содержимого каталога, это инструмент, подобный hashdeep, который можно использовать для вычисления и проверки хешей во всем дереве каталогов. По словам официального сайта этого проекта:

hashdeep - это программа для вычисления, сопоставления и аудита хэш-наборов. При традиционном сопоставлении программы сообщают, совпадает ли входной файл с набором данных или не совпадает ли входной файл. Трудно получить полное представление о состоянии входных файлов по сравнению с набором известных. Можно иметь соответствующие файлы, отсутствующие файлы, файлы, которые были перемещены в наборе, и найти новые файлы, не входящие в набор. Hashdeep может сообщить обо всех этих условиях. Он может даже обнаружить коллизии хеша, когда входной файл соответствует известному файлу в одном алгоритме хеширования, но не в других. Результаты отображаются в отчете об аудите.

Как указано в приведенном выше фрагменте, такой инструмент, как hashdeep, также имеет преимущество, заключающееся в возможности обнаружения файлов, которые, например, были удалены обычным способом. Это то, что проверка целостности данных на уровне файловой системы просто не может сделать, и которая в некоторых ситуациях очень полезна как функция.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .