Re: [devel] rsync_roll

[Alexey Tourbin <at@altlinux.ru>]

[-- Attachment #1: Type: text/plain, Size: 1848 bytes --]

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

А откуда это следует, что точечное изменение в несжатых данных влияет
на конечное число блоков?  А неточечное?  А смещение?  Ведь требуется,
чтобы, как только в двух разных потоках пошли одинаковые данные, так
сразу сумма должна синхронно относительно этих данных обнуляться.

  ABCD-ABCD-ABCD-ABCD-DATA-DATA-DATA-DATA-DATA-		data
   ^     ^   ^  ^     ^    ^   ^   ^    ^		sync
      XYZ-XYZ-XYZ-XYZ-DATA-DATA-DATA-DATA-DATA-
        ^     ^   ^     ^  ^   ^   ^    ^

Какие математические свойства суммы гарантируют, что при появлении
совпадающих данных DATA-DATA- оба процесса суммирования, которые до
этого находились в разных состояниях, достаточно быстро "сойдутся"?

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

Прошу подробнее про стабильность или ссылку.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]