Я спробував спати. Хоча це добре (і має кілька корисних диференційованих функцій, які можуть зробити його кращим вибором для багатьох), але, схоже, скануємо всі цілі файли на контрольні суми.
Яка болісно повільна.
Інші програми з іншого боку, такі як rdfind і rmlint, сканують по-різному.
rdfind має "експериментальну" функцію для використання btrfs reflink. (І "суцільні" варіанти жорстких посилань, посилань тощо)
rmlint має "тверді" параметри для клонування btrfs, reflink, регулярних жорстких посилань, посилань, видалення та власних власних команд.
Але що ще важливіше, rdfind і rmlint значно швидші. Як і в, порядки величини. Замість того, щоб сканувати всі цільові файли на перевірку сум, це робиться приблизно:
- Скануйте всю цільову файлову систему, зібравши лише шляхи та розміри файлів.
- Видаліть з розгляду файли з унікальними розмірами файлів. Це одне, економить час і дискову активність. ("Scads" - це якась обернена експоненціальна функція чи щось таке.)
- З решти кандидатів скануйте перші N байт. Видаліть з розгляду ті, що мають однаковий розмір файлів, але різні перші N байтів.
- Зробіть те саме для останніх N байтів.
- Тільки з тієї (зазвичай крихітної фракції), що залишилася, скануйте контрольні суми.
Інші переваги rmlint я знаю:
- Ви можете вказати контрольну суму. md5 занадто страшно? Спробуйте sha256. Або 512. Або порівняння по бітах. Або ваша власна хеш-функція.
- Він надає вам можливість Btrfs "клонувати" та "reflink", а не просто reflink. "cp --reflink = always" є трохи ризикованим, оскільки він не є атомним, він не усвідомлює, що ще відбувається для цього файлу в ядрі, і не завжди зберігає метадані. "Клон", OTOH (що є скороченим терміном ... Я вказую на офіційне ім'я, пов'язане з API) - це виклик рівня ядра, який є атомним і зберігає метадані. Майже завжди в результаті відбувається одне і те ж, але тест більш надійний і безпечний. (Хоча більшість програм є досить розумними, щоб не видаляти повторюваний файл, якщо він не може спочатку успішно здійснити тимчасове перейменування на інший.)
- Він має багато варіантів для багатьох випадків використання (що також є недоліком).
Я порівнював rmlint з deduperemove - який також сліпо сканує всі цільові файли на контрольні суми. На завершення роботи Duperemove пішло кілька днів (я думаю, 4), пройшовши повний нахил. fmlint знадобилося кілька годин, щоб ідентифікувати дублікати, а потім менше ніж один день, щоб відкласти їх з клоном Btrfs.
(За словами цього, кожен, хто докладе зусиль, щоб написати та підтримати якісне, надійне програмне забезпечення та подарувати його безкоштовно, заслуговує на великі кудо!)
Btw: Вам слід уникати дедупінгу, використовуючи звичайні жорсткі посилання як "загальне" рішення дедупування, будь-якою ціною.
Хоча жорсткі посилання можуть бути надзвичайно зручними у певних випадках цільового використання (наприклад, окремі файли або за допомогою інструменту, який може сканувати певні типи файлів, що перевищують якийсь мінімальний розмір - або як частина багатьох безкоштовних та комерційних рішень для резервного копіювання / знімка), це може бути катастрофічним. для "дедуплікації" у великій файловій системі загального користування. Причина полягає в тому, що більшість користувачів можуть мати тисячі файлів у своїй файловій системі, які є бінарними однаковими, але функціонально зовсім іншими.
Наприклад, багато програм генерують шаблонні та / або приховані файли налаштувань (іноді в кожній папці, яку вона може бачити), які спочатку ідентичні - і більшість залишаються такими, поки вам, користувачеві, не потрібно їх.
В якості конкретної ілюстрації: файли кеш-мініатюр фотографій, які незліченна кількість програм створюється у папці, що містить фотографії (і з поважної причини - переносимість), можуть зайняти години та дні, але потім зробити фотографію додатком вітерцем. Якщо ці початкові файли кешу між собою жорстко пов'язані, ви пізніше відкриєте додаток у каталозі, і він створює великий кеш ... потім здогадайтесь, що: Тепер КОЖНА папка, у якій раніше був кешований кеш, тепер має неправильний кеш. Потенційно, з катастрофічними результатами, які можуть призвести до випадкового знищення даних. А також потенційно таким чином, що вибухає резервне рішення, яке не відомо про жорсткі посилання.
Крім того, це може зруйнувати цілі знімки. Вся суть знімків полягає в тому, що "жива" версія може продовжувати змінюватися, маючи можливість повернутися до попереднього стану. Якщо все міцно пов'язане разом, хоча ... ви "відкочуєтесь" до того ж самого.
Хоча добра новина полягає в тому, що дедупінг з клоном Btrfs / reflink може скасувати цю шкоду (я думаю - оскільки під час сканування він повинен бачити жорсткі файли як однакові ... якщо тільки він не має логіки не вважати жорсткі посилання. Це, мабуть, залежить від конкретна утиліта, що робить виведення.)