После полутора лет разработки опубликован релиз Rsync 3.3.0, утилиты для синхронизации файлов и резервного копирования, позволяющей минимизировать трафик за счёт инкрементального копирования изменений. В качестве транспорта могут быть использованы ssh, rsh или собственный протокол rsync. Поддерживается организация работы анонимных rsync-серверов, оптимально подходящих для обеспечения синхронизации зеркал...Подробнее: https://www.opennet.me/opennews/art.shtml?num=60941
20 лет feature request'у, а воз и ныне там:
unix вей не позволяет реализовать такие вещи эффективно
не звезди, при переименовании inode не меняется.
> при переименовании inode не меняетсяИспользовать inode — не unix way.
и как rsync должен знать про inode?
Тут есть что-то про detect-renamed: https://github.com/RsyncProject/rsync-patches
Если не использовать btrfs/zfs (у которых есть свои средства для снимков и синхронизации), опция --fuzzy работала достаточно хорошо, по крайней мере, в моих случаях. По ссылке она упоминается.Если эту проблему решать в общем случае, надо залезать на уровень кода файловых систем (и там есть варианты) или даже ниже, а rsync всё же уровнем выше живёт, так что идеального решения в нём не получится вообще, а приемлемые за эти годы и так плюс-минус запилили. Но можно рассказать про свой сценарий использования, конечно, коллективный разум помогает, когда действительно хочется проблему решить.
>можно рассказать про свой сценарий использованияСинхронизируется каталог с кучей файлов. В какой-то момент каталог переименовывается без изменения содержимого. Так вот rsync в этом случае на целевой машине создаст новый каталог и будет заново качать все его содержимое. Ни какие --fuzzy и, тем более, btrfs/zfs ситуацию не исправляют.
>надо залезать на уровень кода файловых систем
Абсолютно не требуется. Всего-то надо проверить size, mtime и хэш вложенных файлов (на случай если в переименованом каталоге изменились какие-то файлы) и качать только измененные.
20 лет назад описан этот кейс и даже предложен патч detect-renamed. Упрямство не имеет логического объяснения.
Напомни почему ты за 20 лет не сделал форк с данным патчем хотябы для себя? Может потому что даже у тебя данный кейс ниразу не случился за 20 лет?
> В какой-то момент каталог переименовывается без изменения содержимого.
> Всего-то надо проверитьПолагаю, что для выпускника западного универа это не та семантическая разница, которую можно оценить как "всего-то". Это вполне может пониматься как новая сущность, которую безопасно (и как бы даже легально) обработать именно как новую. Мало ли что файлы с одинаковыми размерами, или даже одинаковые хэши.
Unison вроде умеет такое обрабатывать.
> Unison вроде умеет такое обрабатывать.Я говорю о том, что даже если мы на 101% имеем идентичные файлы, то (для западного универсанта) из этого не следует однозначно возможность считать сущность с другим названием тождественной этой.
>Мало ли что файлы с одинаковыми размерами, или даже одинаковые хэшиДля любого, западного или восточного, реального практика (в смысле "не теоретика") равенство хэшей sha1 означает, что файлы идентичные.
>не та семантическая разницаСферический конь в вакууме.
>>Мало ли что файлы с одинаковыми размерами, или даже одинаковые хэши
> Сферический конь в вакууме.Вот потому у них и многое, а нас не очень, что они к подробностям внимательны, а не отмахиваются.
Сомнительная идея и антифича. Для типичных применений сабжа, это могут быть разные файлы, принадлежащие разным владельцам, и они будут дописываться в нескольких местах одновременно, т.е. хардлинк тут не канает.
> Упрямство не имеет логического объяснения.Если тебя это так тревожит, то первое что тебе следует сделать -- связаться с авторами и узнать их объяснение. У них есть irc-канал или что-то в этом роде? Если есть, то это самое правильное место обсуждать такого рода идеи. Если нет, то значит надо выбрать из активных разработчиков кого-то, и написать ему письмо, с объяснением мотивации, метода решения, ссылкой на патчи, и прямо поставить вопрос: что не так и почему это не принимается в дерево.
Выше описан самый правильный способ искать объяснения, почему патчи не приняты, но можно поспекулировать. Этот метод, во-первых, требует выбора хеш-алгоритма. Это не самый очевидный выбор (коллизии, скорость вычисления хеша...), но при этом важный выбор, который надо делать осознанно, потому что сменить хеш-алгоритм потом может быть затруднительно из-за беквард-совместимости. Во-вторых, этот метод мне лично выглядит недоделанным костылём. Почему сравниваются директории, а не индивидуальные файлы? При чём тут mtime? По-хорошему ведь, напрашивается сравнивать (size, hash) индивидуальных файлов и если они совпадают, то скопировать mtime, права, атрибуты файла и прочее, что копируется, оставив содержимое нетронутым. А если одеть поверх ещё одну "оптимизацию" и сравнивать не только пары (size, hash), но и вектора (size, hash, mtime, user:group, ... всё остальное что заявлено для копирования), и видеть что вектора равны, то пропускать соответствующий файл.
Если уж делать, то как-то так, а не уем об косяк. Потому что если об косяк, то разработчики рискуют потом столкнуться с тем, что предложенный костыль имеет какие-то эдж-кейсы, и ещё хочется функциональность его расширить, но расширить функциональность будет означать сломать обратную совместимость с костыльной реализацией идеи, а значит надо дублировать функциональность некостыльной реализацией.
И поэтому, возвращаясь к началу, тебе надо сначала поговорить с разработчиками и понять, что они думают на этот счёт, в какой форме они готовы принять эту фичу. И когда ты поймёшь, что им надо, вот тогда сесть и написать. План действий ясен? Прекращай скулить, приступай к выполнению.
> Абсолютно не требуется. Всего-то надо проверить size, mtime и хэш вложенных файлов
> (на случай если в переименованном каталоге изменились какие-то файлы) и качать только измененные.Так это ни разу не всего-то, считать хеши всех подряд (ведь мы не знаем, что и куда было перемещено) файлов и держать даже сами хеши (всех-всех файлов в синхронизируемом каталоге и его подкаталогах) в памяти удовольствие совсем не бесплатное и экономия канала тут может вообще не оправдаться. Если какая-то редко нужная функциональность ухудшит жизнь тем кому она не нужна — нехорошо получится всё же.
Лезть на уровень ФС можно чтобы получить информацию о том что такой-то inode был отлинкован от одного каталога и прилинкован к другому (или что вообще тупо каталог был переименован), при этом данные самого файла не менялись. У rsync между запусками не хранится информация об обрабатывавшихся inode, поэтому ему неоткуда об этом узнать. Патч detect-renamed в каких-то ситуациях проблему решает, но не во всех и в комментарии к патчу прямо есть TODO с планами по доработке. В целом, он здраво выглядит, конечно, так что думаю что доделают то что в TODO (если это будет в приоритете, разработчиков-то мало) и замёржат. Но всегда можно наложить локально, если действительно так надо.
В любом случае, спасибо за информацию и пинок подробнее изучить код патчей из rsync-patches.
>экономия канала тут может вообще не оправдатьсяРечь идет совсем не об экономии трафика. Время!
Поясню:
На небольшом сервачке каждую ночь AIDE проверяет неизменность объектов ФС (файлы, линки, директории) одновременно по следующим признакам: permissions, link, user, group, size, mtime, acl, md5
Вот вчерашний лог проверки:
Number of entries: 20891
End timestamp: 2024-04-07 02:12:06 +0300 (run time: 0m 5s)5 (пять!) секунд на 20 тысяч объектов ФС. Суммарный объем этих файлов - 2,8 Гбайт. Если качать их по 100 Мбит линку, то это займет > 280 сек. Даже на скромной виртуалке считать хэши быстрее полной повторной закачки ~ в 50 раз.
а если я не переименовывал, а создал новый каталог (или два, три) и скопировал туда файлы?
> Если не использовать btrfs/zfs (у которых есть свои средства для снимков
> и синхронизации), опция --fuzzy работала достаточно хорошо, по крайней мере,
> в моих случаях. По ссылке она упоминается.
> Если эту проблему решать в общем случае, надо залезать на уровень кода файловых системОна не решается в хорошем виде в общем случае. В CoW видите ли трекинг изменений часть логики работы ФС, оно делается в фоне, всегда.
В случае обычной ФС этого знания просто изначально нет. И вам придется явно угробить ресурсы на его отстраивание и трекинг. Это привносит свой уровень сложности и потребления ресурсов. При том что результат как правило все же хуже чем вон там. Да, дифференциальный btrfs send и точнее, и меньше ресурсов. Что хотите то и делайте с этим фактом. Rsync же скорее для всякой синхры зеркал годится, и даже там грабель - можно огрести от души. Ибо стандартно трекинга отличий нет, полная версия ресурсоемка что капец, а эмпирика - весьма компромиссное решение.
> (и там есть варианты) или даже ниже, а rsync всё же уровнем выше живёт,
> так что идеального решения в нём не получится вообще, а приемлемые за эти годы
> и так плюс-минус запилили. Но можно рассказать про свой сценарий использования,
> конечно, коллективный разум помогает, когда действительно хочется проблему решить.Я бы сказал что рсинк vs вон то все же довольно разные. Скажем делать зеркало скажем репов дистро путем "btrfs send" будет все же несколько странной идеей. Хоть так в принципе и можно при сильном желании.
>20 лет feature request'у, а воз и ныне там:кстати да, ещё очивидную фичу "не выходить с ненулевым error-code когда есть missing files" (совершенно нормальная ситуация, когда живую фс копируешь)
тоже максимально упорото отказались в апстрим взять, вынесли, типа колхозь скрипты, вася...
>Переписан на языке Python perl-скрипт mnt-exclЗачем?
Чтобы хоть кто-то понимал.
Ну как же, а бизапастность?
Питон это Перл сегодня.
Гентушники одобряют.
Ну, вот, есть у тебя, например, мыло, а тебе нужно шило. Или, допустим, наоборот. Вот и меняешь одно на другое.
А если серьёзно, питон - это язык "лёгкий в освоении и удобный в использовании". Кодеров на питоне - как навоза за сараем. Если Служба занятости отправляет безработного филолога или искусствоведа учиться программированию, то в 99% случаев это будут курсы питона. А вот перловщики - это вымирающий вид. Поэтому надо, пока не поздно, найти олдфага, умеющего и в то, и в другое, и заказать ему переписывание перлового скрипта на питон.
Всё правильно понял и описал, только лицо у тебя почему-то недовольное.
Недовольный потому что эти навозные изза сарая хлеб ему отбирают. Масло отобрали уже давно.
Учитывая, что бизнес, сделавший ставку на питон, рано или поздно задаёт себе вопрос типа "а чё у нас всё так тормозит?" или "а чё нам так много за хостинг приходится отваливать?", как раз таки питонята будут постоянными поставщиками хлеба с маслом для таких, как я.
Ты с пхп путаешь. Потому что с пхп как раз таки и переходят на питон.
Разве что не осилившие.
> Ты с пхп путаешь. Потому что с пхп как раз таки и переходят на питон.Ты не в тренде. Таки - на игогошку уже давно - которая питона в вебе и загасит. В общем то - уже.
Ну, если использовать Питон там, где его использовать не желательно, так и будет, в плане замены Питона на что-то более высокопроизводительное. Но в подавляющем числе случаев (до 70-75%, где-то видел диаграмму) эта производительность особо не нужна, зато важна скорость разработки.
Да, только на перловку уже ни один сумасшедший не вернётся. Потому что производительность пхутона с читаемостью опусов Рыбаченко.
Как будто, Перл не интерпретатор и его производительность в разы выше питонячей.
Если бизнес таки раскрутится на питоне, то дальше может спокойно решать стоит ли переходить куда-то еще. История знает таких бизнесов препорядочно, включая мегакорпораций. А вот бизнес даже не родившийся потому что воротил нос от питона вместо того чтобы быстро запустить свою идею на нем как-то даже не жалко. Да про таких никто никогда и не узнает, мало ли что какой васян мечтал сделать но не смог запилить ибо не осилил хардкор.
> Учитывая, что бизнес, сделавший ставку на питон, рано или поздно задаёт себе
> вопрос типа "а чё у нас всё так тормозит?" или "а чё нам так много за хостинг
> приходится отваливать?"Еще раньше они начинают задаваться вопросом "почему все разваливается и постоянно надо переписывать и майнтайнить".
> Поэтому надо, пока не поздно, найти олдфага, умеющего и в то, и в другое, и заказать ему
> переписывание перлового скрипта на питонне надо - он если и правда умеет, пошлет тебя подальше, со словами - работает вот и не трогай (а когда ты ему в красках опишешь какую супернужную и суперсложную фичу не можешь запилить из-за неправильного языка - еще и покажет какую одну строчку надо поправить в двух местах).
Найти надо выпускника филологического факультета с опытом быстрокурсов на пихоне. И поручить переписывать, опционально снабдив доступом к чатгопоте.
Умения - не требуются!
Если нужно что-то поправить/переделать, в питоне это проще и быстрее.
Это наверное затем, что бы то, что работало 20 лет и кушать не просило, теперь радостно переписывать каждые полгода на новую версию петухона. Верной дорогой идут товарищи!
и чтоб никаких рсинков с немодных платформ!
На немодных платформах нет Питона? Очень сомнительно, чтобы сегодня его не было где угодно. ИИ подтверждает.
>опция "-no-overwrite", запрещающая перезапись существующих файлов в целевом каталоге.Синхронизация с удалённым сервером, это по сути перезапись старых и удаление несуществующих файлов. Если запретить перезапись существующих файлов, как всё это получится на практике? Старые файлы будут переименованы?
они просто останутся нетронутыми.А рсинк в первую очередь не для синхронизации, а для копирования большого количества файлов.
> они просто останутся нетронутыми.
> А рсинк в первую очередь не для синхронизации, а для копирования большого
> количества файлов.Слово "sync" в названии как-бы говорит о другом.
на уровне bittorrent sync 1.3.109 есть чё?
synthning - бажная шляпа. rsync не кроссплатформенный
>rsync не кроссплатформенныйА нам кроме экосистемы Линукса ничего не надо.
Пользовался когда-то сборкой для винды. Работало без проблем, но медленно. Теперь пользуюсь robocopy.
использую синхфинг уж десяток лет - умвр :) мож у тебя руки не тем концом не туда вставлены ??
> на уровне bittorrent sync 1.3.109 есть чё?
> synthning - бажная шляпа. rsync не кроссплатформенныйдык в чем проблема ?? платишь за resilio sync и пользуешь в свое удовольствие. btsync аккурат в resilio переименовали.