rsync: возможно ли перемещение скачанных файлов из временного каталога разом?

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

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

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

Ну я в общем-то, пока домой ехал, придумал нечто вроде: сначала запустить рсинк в драй режиме и посмотреть какие файлы он потащит и достаточно просто на первый раз исключить из синхронизации файлы, которые могут иметь зависимости - засинхрить сначала ресурсы, а уж потом можно и эти хоть бы и поодному

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

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

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

это первое что пришло на ум, но в этой модели надо держать две копии всех файлов, а в моем случае это невозможно: если я попрошу двукратное сокращение объема хранилища ради красоты в коде и правильности – менеджмент не поймет :)

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

а если заранее засунуть фильтр расширений файлов ресурсовв find и выхлоп скормить рсинку.
а потом уж все остальное синхронить.
так понимаю разговор идет про html + картинки или что ??

не трожь рсинк,

Чейта? Хочу и трогаю, такой же мой рсинк как и твой! :-Р

он труюниксвей работает в своей стезе и делает это хорошо и отработанно.

за это мы его и любим, я его притащил и заменил им 3000 строк сишного безумия, которые делали то же что рсинк, только медленнее и глючнее, но, правда, вот с различиями в тонкостях. Если победю – разрешат оставить, уменьшу энтропию и вообще выбросы СО2.

хотя стоит рассмотреть ситуацию - притормаживания использующего енти связки приложения.

это получится подгонка задачи под решение

html + картинки

Можно считать что да. Ну, то есть, html файлы не должны появиться в синхронизируемом каталоге раньше картинок. Придумалось сначала запускать рсинк в драй режиме и исключать из первого прохода синхронизации html, если такие там вообще есть, а потом подумалось что это лишние махинации (с драй раном ) и можно тупо запускать рсинк всегда два раза, в первый раз попроив исключить из синхронизации *.html. В любом случае, выйгрыш по скорости, по сравнению с кодом, который я выбрасываю, два-три порядка

держать две копии всех файлов, а в моем случае это невозможно: если я попрошу двукратное сокращение объема хранилища ради красоты в коде и правильности – менеджмент не поймет :)

Ну че так грустно сразу. 21 век, рефлинки вон даже в XFS завезли. Я так гигантские зеркала репозиториев атомарно обновляю и норм.

Насчет как держать две директории с двумя наборами примерно одинаковых файлов, которые не жрут в 2 раза больше места - reflink-и уже посоветовали. От себя посоветую еще и hardlink-и :-)

Во-первых, да, это она, попытка, НО тут так устроено, что приложение живет своей жизнью, а синхронизация своей

Тогда минимум надо проверять что синхронизируемые файлы не открыты на запись. Но все равно не спасет от появления битых файлов.

А использующее их приложение никогда и не открывает их на запись, только синхронизатор.

ЯННП, как линки-то помогут? Я понимаю атомарно и быстро заменить один каталог на другой, подменив линк на каталог (хотя, в принципе, наверное и переименовыванием такое можно), но для этого надо держать два почти одинаковых каталога.

Или есть какой-то тайный способ еще? Линки создать во вреенный каталог на все файлы, и натравить на него рсинк? Ну и чем оно лучше, чем натравить рсинк на первый каталог?

ЯННП, как линки-то помогут?

Допустим у тебя есть каталог data1. Рядом с ним лежит симлинк вида data -> data1. Приложение смотрит в симлинк data.

Делаем копию каталога data1 в data2, используя hardlink. На выходе - второй каталог с точно таким же содержимым, но который почти ничего не весит(накладные расходы на иноды по 4кб на каждый файл)!

Делаем rsync в data2 - лишние файлы(отсутствующие на сервере откуда идет rsync) удаляются(но только из data2, в data1 они по-прежнему лежат), новые файлы добавляются. ВАЖНО: файлы, которые не добавляются/удаляются, а изменяются будут изменены как в data1, так и в data2(потому что хардлинк по суть своей - это тупо ссылка на теже данные под другим именем). Если необходимо этого избежать - нужна ФС со снапшотами(или LVM) и рефлинки(вместо хардлинков) - там такая ситуация разруливается автоматически на уровне ФС(при попытке записи в рефлинк делается копия файла, старый файл остается неизменным). Если речь идет только о добавлении/удалении файлов - то продолжаем дальше.

Когда rsync заканчивается - меняем местами data1 и data2 (или переключаем симлинк, смотря что проще тебе заскриптовать).

Когда требуется новая синхронизация - повторить.

Копий может быть несколько, в случае файловой системы с CoW и рефлинками - все копии займут столько места, сколько там уникальных данных, а не n*примерный размер одной копии.

Спасибо за подробный ответ, надо обмозговать детали, но, вроде подходит!

в случае файловой системы с CoW и рефлинками - все копии займут столько места, сколько там уникальных данных

1 полный размер оригинала + N x размер перезаписанного в рефлинкнутых деревьях. Чтобы было «сколько там уникальных данных», с отловом перемещений внутри файла и дублирования одинаковых изменений в разных деревьях надо ещё после этого дедупликатором пройтись.

Спасибо за уточнение, да, без дедупликации будет весить конечно больше. Но всё равно меньше чем полная копия.

На выходе - второй каталог с точно таким же содержимым, но который почти ничего не весит(накладные расходы на иноды по 4кб на каждый файл)!

Перебор, этак на порядок. Где Вы 4k inodes видели?

Признаю неправоту, но всё же не на порядок. Вот свежая ФС, созданная не больше месяца назад на ядре 5.10:

^_^@phantom ~ # tune2fs -l /dev/mapper/vg-portage_noram | grep -i 'inode s'
Inode size:               2048

Раздел там - 20 гигов(если это имеет значение). Опции дефолтные, размер inode при создании не менял(только сейчас из гугла узнал что его оказывается можно задать)

Однако раньше дефолты были явно другие. Тут раздел уже 2 Tb, создан то ли в 2011, то ли в 2012, точнее не вспомню:

mini-router [~]# tune2fs -l /dev/mapper/fortress-storage | grep -i 'inode s'
Inode size:               256

Update: что кстати странно, потому что на той машине, где ФС с размером inode 2048 в файле /etc/mke2fs.conf четко видно что дефолтный размер inode для ext4 - 256. Хрень какая-то :-/

Признаю неправоту, но всё же не на порядок.

Я не знаю зачем Вам такие большие inodes - много файлов порядка килобайта каждый (чтобы данные в inode держать)?

Но дело даже не в этом - я сам поторопился: hardlink на уже существующий файл дополнительных inodes по определению не стОит, только dir entry (пусть будет пара сотен байт).

И хозяйке на заметку - ext4 походу никогда не реклэймит место занятое директорией, ie нагенерили миллион файлов и потом все грухнули (прожевали) - лучше всю директорию грохнуть и пересоздать, а не просто файлы «внутри» грохнуть.

никогда не реклэймит место занятое директорией

Я хотел сказать «не отпускает»: оно переиспользуется по мере надобности, но в пул свободных блоков не возвращается пока сама директория не прибита.

Так я ж говорю - сам ничего не крутил, использовал дефолты

Так я ж говорю - сам ничего не крутил, использовал дефолты

Очень и очень странно. Я помню дефолты в 128 и 256 байт. Откуда 2k прилетело - для меня загадка.