Есть ли что-то еще, кроме fastcheck, чтобы ускорить Unison?
Я регулярно использую Unison для синхронизации домашних каталогов пользователей между рабочими станциями, на которых ожидается работа пользователя. К сожалению, с ростом фирмы Unison все медленнее и медленнее определяет, какие файлы изменились. Время, затраченное на фактический перевод, незначительно по сравнению.
Синхронизация выполняется в топологии "звезда" с сервером унисон RAID-6 в центре. Некоторые рабочие станции используют Windows (с NTFS), некоторые Linux с Ext-4 или BTRFS(!).
На момент написания статьи был один пользователь, чей домашний каталог размером 45 ГБ и файлы размером 100 КБ, а полная синхронизация у него занимает около 30 минут. Обратите внимание, что простой обход каталога с find >null занимает меньше около 2 минут.
Каковы стратегии дальнейшего ускорения процесса? (кроме сокращения количества файлов для синхронизации) Я считаю, что теоретически Unison может быть ускорен, но fastcheck Варианта не достаточно.
1 ответ
Хорошо, я нашел виновника: унисон игнорирует fastcheck вариант для xls а также mpp файлы и всегда выполняет полное сравнение для них. Это происходит потому, что Excel имеет привычку изменять файлы xls без изменения даты последнего изменения.
К сожалению для нас, xls составляет около 20% от общего объема документов.
Редактирование /usr/bin/unison в шестнадцатеричном редакторе и замене xls за то, что вряд ли можно найти (как xxx) сделал свое дело.
В файловых системах Unix (btrfs, ext4) эта процедура должна быть безопасной, так как любое изменение файла должно изменить номер инода, и unison должен использовать эту информацию, если она доступна. Что касается клиентов, основанных на ntfs, я думаю, что мы должны страдать из-за медленного времени... или, может быть, есть какая-то альтернатива (отказ от Excel или изменение файловой системы).
После этого взлома унисон ускорился более десяти раз!