Re: [devel] rsync_roll

["Alexander Myltsev" <avm@altlinux.ru>]

2008/5/25 Alexey Tourbin <at@altlinux.ru>:
>> http://ozlabs.org/~rusty/gzip.rsync.patch2, на который ссылаются как
>> Джефф, так и Эгмонт.
> Что делает этот патч?  Почему "это работает"?
>
> Когда сумма принимает определённое значение (а именно, когда
> sum % RSYNC_WIN == 0) то в конце окна принимается решение
> "сборосить блок" и заново инициализировать процедуру сжатия.
>
> Это означает, что в этой точке как бы начинается "новый файл",
> который gzip будет жать отдельно; если в двух разных входных
> потоках в точке обнуления суммы несжатые данные идут одинаковые,
> то и сжатые данные пойдут одинаковые.

Ну да, это и требуется. Благодаря этому точечное изменение в несжатых
данных влияет только на конечное число блоков.

Можно попробовать рассматривать функцию сжатия блока как чёрный ящик.
Тогда очевидно, что для rsyncability важно правильным (стабильным)
образом разбивать входные данные на блоки. Предлагаемый патч задаёт
локально стабильный способ разбиения на блоки.

> а размер окна 4K.  Поскольку любое значение суммы по модулю 4096
> можно считать равновероятным, то, выходит, что вместо блока 32K
> gzip будет делать блоки в среднем по 4K.  Или нет?

4K исходных данных съедается сразу после обнуления суммы, см.
комментарий "not enough elements" в rsyncable.c. То есть 4K — это
минимальный размер блока. Только после этого мы начинаем искать нуль,
а находим его ещё примерно через 4K. Вот вам и экспериментальные 8K.