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