On Thu, May 29, 2008 at 10:37:44PM +0400, Dmitry V. Levin wrote:
> On Thu, May 29, 2008 at 05:28:39PM +0400, Alexander Bokovoy wrote:
> [...]
> > Я в этом деле лицо скорее заинтересованное, но я бы выбрал rsyncable
> > против lzma, потому что это дает следующие преимущества:
> > 1. Позволяет более полно использовать состояние зеркала на стороне пользователя.
> 
> Несмотря на неизменность большинства файлов, и постоянные переименования
> большинства из оставшихся файлов?

Также следует понимать, что rsyncable deflate работает только для
достаточно больших (порядка 32K) полностью совпадающих кусков.
На практике это значит, что в *.rpm пакетах из синхронизации исключаются
маленькие файлы.  Например, для пакета man-pages rsyncable оптимизация
почти ничего не даёт (speedup 1.09 после _простой_ повторной
пересборки).  Это связано с тем, что в cpio хедере (перед содержимым
файла) есть mtime, и он получается всё время разный.  А различие в mtime
"надолго" сбивает синхронизацию (то есть весь "маленький" файл
выпадает).

У меня есть идея.  Для выбора точек синхронизации (gzflush) можно
использовать не только "слепой" rsync hint, но и cpio hint -- как
только мы видим cpio magic "070707", мы знаем, что через несколько
байтов будет mtime и потом пойдёт имя и содержимое файла.  То есть
sync можно делать в месте окончания очередного cpio header.

Правда, я не знаю, даст это что-нибудь в случае с маленькими файлами
или нет.  Это может ничего не дать из-за того, что первые совпавшие
блоки в сжатом виде всё равно могут отличаться (из-за backreferences
в предыдущий блок).