LINUX.ORG.RU

Как максимально быстро проверять целостность больших медиафайлов

 , ,


1

4

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

find -type f -exec %CMD% '{}' \; > checksum

Но использование всяких md5/sha* это очень долго для больших файлов. Если брать файлы кусками, например, первые 1/10/100 мб, и прогонять через алгоритм, будет ли это достаточно надежным способом проверить целостность файла? Или может есть какие-то спец. алгоритмы, заточенные на работу с медиа? Как вы это делаете?

Если брать файлы кусками, например, первые 1/10/100 мб, и прогонять через алгоритм, будет ли это достаточно надежным способом проверить целостность файла?

Если тебе пофиг на ошибки в файлах за пределами первых 1-10-100 Мб, зачем вообще проверять? Что такова важного в начале файла? Если нужна проверка целостности файла, вариант только один - проверка от начала до конца.

sigurd ★★★★ ()

Понятно, что это будет что-то вроде

А может лучше вот так: https://github.com/rfjakob/cshatag Теже хэшсуммы, но примотанные сразу к файлам

gutaper ★★★★ ()

Как вы это делаете?

cfv

очень долго для больших файлов.

Займись чем-то полезным в процессе проверки.

YAR ★★★★★ ()

В этом смысле хеши кусков позволят только быстрее отрапортовать о первой ошибке.

Если так надо кусками, то торрент запихивать в xattrs?

zfs/btrfs не хочу, потому что не считаю их удобными и готовыми

В xfs, вроде, добавили CRC.

Есть еще на блочном уровне dm-verity для неизменяемых, но сильно неудобен. dm-integrity для изменяемых - новее, тоже не очень удобен, если не использовать в связке с LUKS. Скорость записи падает в два раза в режиме с журналом, как раньше на ФС с барьерами.

boowai ★★★★ ()
Последнее исправление: boowai (всего исправлений: 1)

http://www.xxhash.com/

31 GB/sec - куда тебе быстрей? Ты просто только про попсовые хеш функции знаешь

menangen ★★★★★ ()

Но использование всяких md5/sha* это очень долго для больших файлов.

Банальность, но чтобы проверить файл нужно прочитать файл, и это здесь самая дорогая операция - скорость конкретного хешера не важна. Теоретически можно ускорится запуская несколько потоков чтобы диск не простаивал. Сильно зависит от конкретного железа. Но выше головы (скорости диска) Вы всё равно не прыгните.

Как вы это делаете?

Лично я храню md5sum файлы, один на директорию. Когда наступает паранойя - обхожу используя find + xargs + «md5sum -с» + «egrep -v»

bugfixer ()
Ответ на: комментарий от sigurd

Council of State Archivists в рамках программы State Electronic Records Initiative сделало наглядную презентацию о bit rot: https://invidious.snopyta.org/watch?v=a50B801U0RA (оригинал на YouTube).

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

dm-integrity может в этом помочь, как отдельно, так и в связке с LUKS 2. Для пущей надёжности можно отказаться от алгоритма верификации CRC в пользу sha1/sha256 или даже HMAC. С CRC скорость будет значительно выше, но, скорее всего, решающей будет скорость чтения из накопителя.

Pravorskyi ★★ ()
Последнее исправление: Pravorskyi (всего исправлений: 1)

Если брать файлы кусками, например, первые 1/10/100 мб, и прогонять через алгоритм, будет ли это достаточно надежным способом проверить целостность файла?

Если это единичный bit flip, то, возможно, он не повлияет на большой медиафайл, ну или испортит несколько кадров. А если случится silent data corruption с самым накопителем во время бэкапа? Поиск в интернете показывает много интересных историй. Нужно оценивать риски и важность данных, а там и до ECC RAM можно дойти.

Pravorskyi ★★ ()
Последнее исправление: Pravorskyi (всего исправлений: 1)
Ограничение на отправку комментариев: только для зарегистрированных пользователей