Intereting Posts
Wi-Fi перестает работать после приостановки или при повторном подключении (не происходит каждый раз, исправления перезагрузки) «Multipass» скриптовая модификация большого файла на месте (уровень файловой системы)? Как подключиться к графической среде на CentOS 6 из Windows 7? awk, чтобы суммировать числа (плавающие) и сгруппировать их по уникальному ключу Почему нет команды оболочки для создания файлов? Добавление маршрута с ограниченным сроком действия? Правила SELinux применяются до или после стандартных разрешений linux? Система Debian – Clone Как создать плагины dnscrypt? bashrc ленивая замена Восстановить моментальный снимок Btrfs из подкаталога в родительский Почему (“) дает список, а $ () дает только один аргумент SSH-туннель с различным портом ssh Синхронизация каталогов через SSHFS с символическими ссылками Сетевое взаимодействие с мостами Linux

Отчеты каталогов с содержимым, которое существует в другом месте, даже если они разбросаны

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

Другими словами, структура каталога и его содержание не будут идентичны. Но 100% содержащихся файлов, по отдельности, будут продублированы … где-то, где угодно, на одной и той же FS.

Учитывая мой рабочий процесс и пример использования ниже, должно быть ясно, что это почти всегда будут односторонние отношения. 100% содержимого файла dir1 может существовать в другом месте с разными именами файлов и структурами каталогов, часто более чем одна копия на файл.

Например, копии dir1 / file1 могут существовать в dir2 и dir3. Копии dir1 / file2 могут существовать в dir2 и dir4. dir2, dir3 и / или dir4 также могут содержать свои собственные уникальные файлы, а также копии файлов из других каталогов. Но dir1 вполне может быть безопасно удален.

Другими словами, обратной корреляции нет: dir1 имеет 100% избыточность; но dir2, dir3, dir4 … и т. д. не обязательно (Они могут и, следовательно, могут также быть кандидатами на удаление, но на данный момент основным кандидатом является dir1.)

Остальная часть этого вопроса не является обязательной для прочтения, чтобы понять и ответить на вопрос. Он просто отвечает на некоторые потенциальные вопросы касательно «почему?» И «вы пробовали…?».

Вот пример использования, генерирующий потребность, которая на самом деле кажется довольно распространенной (или, по крайней мере, не редкой). … хотя бы с вариациями на конечный результат:

  1. На месте:
    1. Я беру ГБ фотографий и видео.
    2. Каждый день я перемещаю файлы с карт памяти в папки, упорядоченные по имени камеры и дате, на избыточный массив портативных жестких дисков USB.
    3. Когда у меня есть время, я организовываю копии этих файлов в структуру папок, например «(фото | видео) / год / дата», с именами файлов, начинающимися с «yyyymmdd-hhmmss». (Другими словами, исходная структура полностью зашифрована. И не всегда таким предсказуемым образом.) Эти организованные копии идут на SSD-диск для более быстрого рабочего процесса, но я оставляю исходные неуправляемые копии в медленном избыточном хранилище для резервного копирования, с физическим разделением копий, кроме как на этапе копирования.
  2. Возвратиться домой:
    1. Я перемещаю все неуправляемые файлы из массива жестких дисков USB в «постоянный» (больший, более надежный и постоянно поддерживаемый облачным хранилищем) массив в качестве исходного источника правды в случае, если мой рабочий процесс идет вбок.
    2. Делайте постобработку на организованных копиях на SSD. (Оставить исходные необработанные файлы без изменений, кроме переименования, и сохранить изменения в новых файлах.
    3. Когда я закончу и сделаю все, что планировалось с результатами, я перемещаю всю файловую структуру SSD в тот же «постоянный» массив большего размера, что и оригиналы. (Но помните, что структура каталогов полностью отличается от структуры дампа SD-карты.)

В идеале в этом рабочем процессе я бы также удалил оригинальные папки дампа карт, которые теперь не нужны. Проблема в том, что, как и в жизни, мой рабочий процесс постоянно прерывается. Либо у меня нет времени, чтобы закончить организацию на месте, либо он задерживается на некоторое время дома, либо я не организовываю точно так же каждый раз, либо я просто запутываюсь в том, что существует, где и я боюсь что-нибудь удалить. Часто перед отправлением я делаю копию переносного носителя на постоянный массив на всякий случай, даже если я подозреваю, что он уже может существовать 2 или 3 раза. (Я не ОКР. Просто травмирован опытом.) Иногда (реже в последующие годы) я реорганизую всю свою структуру логических каталогов. В других случаях я обновляю его в середине streamа, оставляя в покое предыдущие. В течение многих лет я также перемещался и полностью забыл, куда (и как) отправляются файлы «сброс карты». Иногда мой рабочий процесс на месте, как он четко определен и протестирован, приводит к неопределенному состоянию различных папок, поэтому я делаю еще больше резервных копий «на всякий случай». Я также писал программы, которые создавали тысячи символических ссылок на папки, чтобы по-разному просматривать мою массивную структуру папок. (Как и в «сводной таблице» файловой системы.) Но затем rsync’ed всю файловую систему для замены массивов, забыв установить флаги «сохранить жесткие ссылки и символические ссылки» и свернуть копии, которые ранее были просто ссылками, а затем Со временем пропали треки, из которых были фактически оригиналы. (Попробуйте сделать это с 20 годами фотографий / видео и 30 годами других данных с лучшими результатами!)

Другими словами, у меня повсюду миллионы больших файлов, большая часть которых излишне избыточна, в большом красивом беспорядке. И мне нужно это исправить. Не только для того, чтобы сэкономить место (о котором давно позаботились), но и для того, чтобы уменьшить путаницу того, что находится в безопасном месте (и, что более важно, канонически). Первый шаг в этом для меня состоит в том, чтобы удалить тысячи папок с содержимым, которое я знаю с высокой степенью достоверности (не обязательно достоверной), которое на 100% распределено в другом месте. Даже если каждый кандидат на удаление требует быстрой ручной проверки.

Он генерирует первоначальный список, который по-человечески невозможен за одну жизнь. В идеале, список должен быть «все файлы в этом каталоге существуют в другом месте, но в другом макете каталога, причем эти каталоги также содержат несоответствующие файлы». Но, как минимум, « все файлы в этом каталоге также существуют в другом месте ».

Я исследовал и протестировал около десятка решений для дедупликации, некоторые из которых очень далеки от решения этой проблемы, но не достаточно близко. В моем «постоянном» массиве встроенная дедупликация ZFS включена в течение многих лет. Несмотря на то, что это сокращает пропускную способность записи примерно до 25%, я могу позволить себе подождать, но я не могу позволить себе многие тысячи долларов в дополнительном дисковом пространстве, которое понадобилось бы для пары десятилетий в два раза, а иногда и в трехкратном дублировании фотографий и видеоданные (не говоря уже о том, что они хранятся на полосе трехсторонних зеркал).

Я только что подготовил локальный автоматический массив резервного копирования (для дополнения облачного резервного копирования). Я использовал Btrfs RAID1, чтобы избежать потенциальных проблем, связанных с использованием одного и того же программного обеспечения для хранения данных с одинаковыми ошибками в одно и то же время. (Что случалось со мной раньше в ZFS, к счастью, это приводило только к временной невозможности монтирования.) Также это решение обладает прекрасной возможностью легко масштабировать массив по одному диску за раз. :-), что хорошо, потому что это очень дорогое и трудоемкое предложение для моего большого первичного массива ZFS.

В любом случае, единственная причина, которая имеет отношение к этому вопросу, заключается в том, что Btrfs имеет множество хороших утилит для дедупликации в автономном режиме, которые, как я уже сказал, некоторые из них дразнящим образом подходят к решению этой проблемы, но этого недостаточно. Краткое резюме того, что я пробовал:

  • rdfind : алгоритм быстрого сопоставления, отлично подходит для дедупликации через жесткие ссылки. Проблема в том, что это может привести к катастрофе для любого пользователя (всех пользователей?). Несмотря на то, что это частично оправдывало мое совершенно отдельное требование экономии места среди больших избыточных мультимедийных файлов независимо от имени или местоположения, я обнаружил, что это пагубно для других вещей, которые нельзя легко распутать. Например, он также жестко связывает вместе другие идентичные файлы, которые не имеют отношения к одному и тому же файлу. Например, различные файлы метаданных, которые автоматически генерируют операционные системы и приложения, большинство из которых одинаковы в сотнях или тысячах каталогов, но абсолютно должны быть разными. Например, «Thumbs.db», и обращение к одному и тому же файлу может и почти наверняка приведет к потере данных позже – возможно, тривиально, а может и нет.) У него есть возможность дедупликации ссылок Btrfs (которые могут позже дифференцироваться с CoW), но это Особенность помечена как «экспериментальная».
  • duperemove : дедуплицируется с помощью рефлинков Btrfs, так что это приемлемый (отличный, даже) подход для экономии места на диске и одновременного расхождения файлов. (За исключением того, что в настоящее время Btrfs, по-видимому, не дедуплицирует файлы при деfragmentации [в зависимости от ядра?], Даже моментальные снимки. Что за чудак, но я избегаю его, никогда не деfragmentируя и не соглашаясь с последствиями.) Проблема с двусторонним удалением заключается в том, что, поскольку вслепую проверяет контрольные суммы каждого файла в поиске, он невероятно медленный и долго и усердно работает с дисками. Это в основном выполняет скраб массива бедняков. Занимает несколько дней на моем массиве. (bedup, пчелы и некоторые другие похожи в этом отношении, даже если они сильно отличаются друг от друга. rdfind и некоторые другие умнее. Сначала они сравнивают размеры файлов. Затем сначала несколько байтов. Затем последние несколько байтов. Только когда все совпадают прибегает к контрольной сумме.)
  • rmlint : в настоящее время это лучше всего подходит для других моих требований – просто сэкономить место на диске. У него есть два варианта рефлинкинга Btrfs (атомарное клонирование в режиме ядра и чуть менее надежный метод cp –reflink). Алгоритм сканирования – самый быстрый, который я тестировал; хеширование может быть увеличено до sha256 и выше (в том числе побитно); и у него есть много полезных опций, чтобы удовлетворить многие из моих требований. (За исключением, насколько я могу судить, одного в этом вопросе.)

Есть много других утилит для дедупликации, в том числе fdupes, fslint и т. Д. Я в значительной степени протестировал (или прочитал о них) их все, даже если у них нет поддержки Btrfs (поскольку это в основном не имеет отношения к этому вопросу). Ни один из них, за исключением, возможно, rmlint, не приблизился к тому, что мне нужно.

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

После того, как вы это сделаете, если у вас есть один каталог, содержащий только файлы с количеством ссылок больше единицы, вы знаете, что каждый из файлов существует где-то еще на диске.

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

Этот пример не обращается к пробелам в именах файлов или каталогов.

 for dir in `find . -type d`; do if test -z "$(find $dir -maxdepth 1 -links 1 -quit)"; then echo $dir fi done