[devel] rpm: LZMA payload compression

[devel] rpm: LZMA payload compression

[Alexey Tourbin]

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

Я портировал SuSE патчи для LZMA сжатия payload (cpio архива)
в rpm пакетах.  (Портировал -- громоке слово, код править не пришлось.)

Это имеет следующие особенности.

1) Собрана статическая библиотека liblzma.a из
git://ctrl.tukaani.org/lzma-utils.git.  Код этой библиотеки производит
хорошее впечателение, но разработчики пишут о том, что API ещё не
заморожен (а при использовании этой библиотеки создаются non-opaque
структуры, что усложняет контроль бинарной совместимости).  Чтобы
не облажаться, librpmio.so пока будет включать в себя копию liblzma.a.

2) Для Сизифа по умолчанию будет включен режим сжатия w2.lzdio,
как для _source_payload, так и для _binary_payload (вероятно,
сизифовская сборка после проверки будет отправлена в branch 4.1).
В branch 4.0 будет отправлена сборка с поддежкой lzdio, но
сжатие будет по умолчанию выключено (останется w9.gzdio).
В обоих случаях сам rpm будет собран с w9.gzdio, чтобы его
можно было обновить предыдущим rpm'ом без поддержки lzdio.

3) Выбранный уровень сжатия 2 обеспечивает высокую скорость сжатия
(быстрее, чем у w9.bzdio, но несколько медленнее, чем у w9.gzdio)
и степень сжатия, сравнимую с w9.bzdio (иногда -- несколько лучше).
Следующий уровень сжатия 3 по скорости уже заметно проигрывает bzdio
(хотя и жмёт несколько лучше).  Скорость разжатия не зависит от уровня
сжатия (разжимает примерно в 3 раза медленнее, чем gzip, но при этом
в 3-4 раза быстрее, чем bzip2).

3) У пакетов, собранных со сжатием lzdio, появится зависимость
rpmlib(PayloadIsLzma) <= 4.4.2-1.  apt разрешает эту зависимость
через librpm, доступный ему в хост-системе.  Но практике это означает,
что a) до установки любого пакета с lzdio сжатем нужно (отдельной
транзакцией) обновить сам rpm; б) для сборки пакетов хешером
в хост-системе должен стоять rpm с поддержкой lzdio.

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

Re: [devel] rpm: LZMA payload compression

[Andrey Rahmatullin]

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

On Sat, May 24, 2008 at 06:21:14PM +0400, Alexey Tourbin wrote:
> что a) до установки любого пакета с lzdio сжатем нужно (отдельной
> транзакцией) обновить сам rpm;
Т.е. тупой dist-upgrade обломится?

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

<ravil> а что не так с альсой в стд-деф?
<raorn> она утонула (ц)

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

Re: [devel] rpm: LZMA payload compression

[Alexey Tourbin]

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

On Sat, May 24, 2008 at 08:20:01PM +0600, Andrey Rahmatullin wrote:
> On Sat, May 24, 2008 at 06:21:14PM +0400, Alexey Tourbin wrote:
> > что a) до установки любого пакета с lzdio сжатем нужно (отдельной
> > транзакцией) обновить сам rpm;
> Т.е. тупой dist-upgrade обломится?

apt выдаст unmet, если в транзакцию на обновление попадёт хотя бы
один пакет с rpmlib(PayloadIsLzma).

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

Re: [devel] rpm: LZMA payload compression

[Dmitry V. Levin]

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

On Sat, May 24, 2008 at 06:32:55PM +0400, Alexey Tourbin wrote:
> On Sat, May 24, 2008 at 08:20:01PM +0600, Andrey Rahmatullin wrote:
> > On Sat, May 24, 2008 at 06:21:14PM +0400, Alexey Tourbin wrote:
> > > что a) до установки любого пакета с lzdio сжатем нужно (отдельной
> > > транзакцией) обновить сам rpm;
> > Т.е. тупой dist-upgrade обломится?
> 
> apt выдаст unmet, если в транзакцию на обновление попадёт хотя бы
> один пакет с rpmlib(PayloadIsLzma).

В течение переходного периода в сборочной песочнице придётся включить
обратно w9.gzdio для бинарных пакетов.


-- 
ldv

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

Re: [devel] rpm: LZMA payload compression

[Alexander Bokovoy]

24 мая 2008 г. 18:21 пользователь Alexey Tourbin <at@altlinux.ru> написал:
> 3) Выбранный уровень сжатия 2 обеспечивает высокую скорость сжатия
> (быстрее, чем у w9.bzdio, но несколько медленнее, чем у w9.gzdio)
> и степень сжатия, сравнимую с w9.bzdio (иногда -- несколько лучше).
> Следующий уровень сжатия 3 по скорости уже заметно проигрывает bzdio
> (хотя и жмёт несколько лучше).  Скорость разжатия не зависит от уровня
> сжатия (разжимает примерно в 3 раза медленнее, чем gzip, но при этом
> в 3-4 раза быстрее, чем bzip2).
Два вопроса по производительности:
1. Насколько это ускоряет типичную установку пакетов? Скажем, kde или
что-нибудь подобное по объему?
2. Насколько этот режим совместим с rsync? Сам по себе LZMA не очень
приспособлен к генерации блочных структур.
3. Использует ли реализация в rpm возможности порождения
дополнительных потоков, как это сделано в 7z?

-- 
/ Alexander Bokovoy

Re: [devel] rpm: LZMA payload compression

[Alexey Tourbin]

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

On Sat, May 24, 2008 at 06:51:00PM +0400, Alexander Bokovoy wrote:
> 24 мая 2008 г. 18:21 пользователь Alexey Tourbin <at@altlinux.ru> написал:
> > 3) Выбранный уровень сжатия 2 обеспечивает высокую скорость сжатия
> > (быстрее, чем у w9.bzdio, но несколько медленнее, чем у w9.gzdio)
> > и степень сжатия, сравнимую с w9.bzdio (иногда -- несколько лучше).
> > Следующий уровень сжатия 3 по скорости уже заметно проигрывает bzdio
> > (хотя и жмёт несколько лучше).  Скорость разжатия не зависит от уровня
> > сжатия (разжимает примерно в 3 раза медленнее, чем gzip, но при этом
> > в 3-4 раза быстрее, чем bzip2).
> Два вопроса по производительности:
> 1. Насколько это ускоряет типичную установку пакетов? Скажем, kde или
> что-нибудь подобное по объему?

Это не может ускорить установку пакетов, потому что скорость разжатия
раза в три меньше, чем у gzip, который сейчас используется (но при этом
раза в 3-4 больше, чем у bzip2).

Точнее, на это лучше смотреть по-другому.  Скорость разжатия LZMA на
современных процессорах (2GHz) -- 20 Mb/s.  Это неплохо соотносится
со скоростью современных дисков и media.  Например, если *.rpm пакеты
с DVD читаются медленнее, чем 20 MB/s (чем процессор успевает их
распаковывать), то установка пойдёт несколько быстрее (за счёт того,
что при LZMA сжатии *.rpm пакеты занимают меньше места на DVD).

> 2. Насколько этот режим совместим с rsync? Сам по себе LZMA не очень
> приспособлен к генерации блочных структур.

Не знаю.  В текущем виде gzdio тоже создаёт payload, который rsync
"не берёт".  К тому же rsync синхронизирует только файлы с одинаковыми
названиями (точнее, у rsync есть опция -y, но я не уверен, что она
всегда хорошо работает).

> 3. Использует ли реализация в rpm возможности порождения
> дополнительных потоков, как это сделано в 7z?

В lzdio используется формат LZMA_Alone.  Больше об этом я сейчас ничего
сказать не могу, но постараюсь ещё почитать исходники и разобраться.

А что дают "дополнительные потоки" в 7z?

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

Re: [devel] rpm: LZMA payload compression

[Alexey Tourbin]

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

On Sat, May 24, 2008 at 07:35:09PM +0400, Alexey Tourbin wrote:
> Точнее, на это лучше смотреть по-другому.  Скорость разжатия LZMA на
> современных процессорах (2GHz) -- 20 Mb/s.  Это неплохо соотносится
> со скоростью современных дисков и media.  Например, если *.rpm пакеты
> с DVD читаются медленнее, чем 20 MB/s (чем процессор успевает их
> распаковывать), то установка пойдёт несколько быстрее (за счёт того,
> что при LZMA сжатии *.rpm пакеты занимают меньше места на DVD).

Кажется, я плохо подумал.  Скорость разжатия 20 Mb/s это имеется
в виду 20 Mb разжатых данных.  То есть чтобы выдать на выходе 20 Mb,
сжатых данных нужно прочитать гораздо меньше.  Значит, tradeoff время
чтения/время разжатия в случае с lzma едва ли имеет место быть (если
только на очень медленных media).

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

Re: [devel] rpm: LZMA payload compression

[Alexander Bokovoy]

24 мая 2008 г. 19:35 пользователь Alexey Tourbin <at@altlinux.ru> написал:
>> Два вопроса по производительности:
>> 1. Насколько это ускоряет типичную установку пакетов? Скажем, kde или
>> что-нибудь подобное по объему?
>
> Это не может ускорить установку пакетов, потому что скорость разжатия
> раза в три меньше, чем у gzip, который сейчас используется (но при этом
> раза в 3-4 больше, чем у bzip2).
>
> Точнее, на это лучше смотреть по-другому.  Скорость разжатия LZMA на
> современных процессорах (2GHz) -- 20 Mb/s.  Это неплохо соотносится
> со скоростью современных дисков и media.  Например, если *.rpm пакеты
> с DVD читаются медленнее, чем 20 MB/s (чем процессор успевает их
> распаковывать), то установка пойдёт несколько быстрее (за счёт того,
> что при LZMA сжатии *.rpm пакеты занимают меньше места на DVD).
Было бы интересно увидеть конкретные цифры установок в хэшере.

>
>> 2. Насколько этот режим совместим с rsync? Сам по себе LZMA не очень
>> приспособлен к генерации блочных структур.
>
> Не знаю.  В текущем виде gzdio тоже создаёт payload, который rsync
> "не берёт".  К тому же rsync синхронизирует только файлы с одинаковыми
> названиями (точнее, у rsync есть опция -y, но я не уверен, что она
> всегда хорошо работает).
Дело в том, что gzip имеет код, который позволяет создавать архивы,
построенные на фиксированных блоках (опция --rsyncable в утилите
gzip), наверняка такую же настройку можно активировать и в библиотеке.
С этими фиксированными блоками rsync очень хорошо справляется.

>> 3. Использует ли реализация в rpm возможности порождения
>> дополнительных потоков, как это сделано в 7z?
>
> В lzdio используется формат LZMA_Alone.  Больше об этом я сейчас ничего
> сказать не могу, но постараюсь ещё почитать исходники и разобраться.
>
> А что дают "дополнительные потоки" в 7z?
В большинстве машин, выпущенных в последние год-два уже есть два
аппаратных потока (core или threads). Реализация LZMA в 7zip
многопоточна и позволяет порождать несколько потоков при упаковке и
увеличивать производительность за счет параллелизации. Это, увы, не
относится к распаковке.
-- 
/ Alexander Bokovoy

Re: [devel] rpm: LZMA payload compression

[Andrey Rahmatullin]

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

On Sat, May 24, 2008 at 07:53:55PM +0400, Alexander Bokovoy wrote:
> Дело в том, что gzip имеет код, который позволяет создавать архивы,
> построенные на фиксированных блоках (опция --rsyncable в утилите
> gzip)
Это патч, которого у нас нет, ибо нестабильный. Сто раз обсуждалось.

$ gzip --rsyncable
gzip: unrecognized option `--rsyncable'

https://bugzilla.altlinux.org/show_bug.cgi?id=8184
https://bugzilla.altlinux.org/show_bug.cgi?id=8185

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

<roman> это, а у нас xneur кто-то пользует? у меня он иксы убивает
<Vitls> xneur - X server Neutralizator

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

Re: [devel] rpm: LZMA payload compression

[Alexander Bokovoy]

24 мая 2008 г. 19:58 пользователь Andrey Rahmatullin <wrar@altlinux.ru> написал:
> On Sat, May 24, 2008 at 07:53:55PM +0400, Alexander Bokovoy wrote:
>> Дело в том, что gzip имеет код, который позволяет создавать архивы,
>> построенные на фиксированных блоках (опция --rsyncable в утилите
>> gzip)
> Это патч, которого у нас нет, ибо нестабильный. Сто раз обсуждалось.
>
> $ gzip --rsyncable
> gzip: unrecognized option `--rsyncable'
>
> https://bugzilla.altlinux.org/show_bug.cgi?id=8184
> https://bugzilla.altlinux.org/show_bug.cgi?id=8185
Патч Rusty уже довольно давно используется в Debian без проблем. Может
стоит пересмотреть? Тем более, что именно на этот код нареканий у
Святослава не было -- он модифицирует только сжатие, а не распаковку,
с которой у него были проблемы.
-- 
/ Alexander Bokovoy

Re: [devel] rpm: LZMA payload compression

[Alexander Bokovoy]

24 мая 2008 г. 19:53 пользователь Alexander Bokovoy <ab@altlinux.org> написал:
> 24 мая 2008 г. 19:35 пользователь Alexey Tourbin <at@altlinux.ru> написал:
>>> Два вопроса по производительности:
>>> 1. Насколько это ускоряет типичную установку пакетов? Скажем, kde или
>>> что-нибудь подобное по объему?
>>
>> Это не может ускорить установку пакетов, потому что скорость разжатия
>> раза в три меньше, чем у gzip, который сейчас используется (но при этом
>> раза в 3-4 больше, чем у bzip2).
>>
>> Точнее, на это лучше смотреть по-другому.  Скорость разжатия LZMA на
>> современных процессорах (2GHz) -- 20 Mb/s.  Это неплохо соотносится
>> со скоростью современных дисков и media.  Например, если *.rpm пакеты
>> с DVD читаются медленнее, чем 20 MB/s (чем процессор успевает их
>> распаковывать), то установка пойдёт несколько быстрее (за счёт того,
>> что при LZMA сжатии *.rpm пакеты занимают меньше места на DVD).
> Было бы интересно увидеть конкретные цифры установок в хэшере.
>
>>
>>> 2. Насколько этот режим совместим с rsync? Сам по себе LZMA не очень
>>> приспособлен к генерации блочных структур.
>>
>> Не знаю.  В текущем виде gzdio тоже создаёт payload, который rsync
>> "не берёт".  К тому же rsync синхронизирует только файлы с одинаковыми
>> названиями (точнее, у rsync есть опция -y, но я не уверен, что она
>> всегда хорошо работает).
> Дело в том, что gzip имеет код, который позволяет создавать архивы,
> построенные на фиксированных блоках (опция --rsyncable в утилите
> gzip), наверняка такую же настройку можно активировать и в библиотеке.
> С этими фиксированными блоками rsync очень хорошо справляется.
Вот, кстати, подробное исследование применимости rsync к репозитариям,
которое было выполнено на основе debian-подобного дистрибутива и alt
linux (Святослав Свиридов как раз тогда эти патчи для нашего apt/rsync
написал) пять лет назад.
http://lists.debian.org/debian-devel/2003/07/msg00462.html

-- 
/ Alexander Bokovoy

Re: [devel] rpm: LZMA payload compression

[Alexey Tourbin]

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

On Sat, May 24, 2008 at 07:53:55PM +0400, Alexander Bokovoy wrote:
> 24 мая 2008 г. 19:35 пользователь Alexey Tourbin <at@altlinux.ru> написал:
> >> Два вопроса по производительности:
> >> 1. Насколько это ускоряет типичную установку пакетов? Скажем, kde или
> >> что-нибудь подобное по объему?
> >
> > Это не может ускорить установку пакетов, потому что скорость разжатия
> > раза в три меньше, чем у gzip, который сейчас используется (но при этом
> > раза в 3-4 больше, чем у bzip2).
> >
> > Точнее, на это лучше смотреть по-другому.  Скорость разжатия LZMA на
> > современных процессорах (2GHz) -- 20 Mb/s.  Это неплохо соотносится
> > со скоростью современных дисков и media.  Например, если *.rpm пакеты
> > с DVD читаются медленнее, чем 20 MB/s (чем процессор успевает их
> > распаковывать), то установка пойдёт несколько быстрее (за счёт того,
> > что при LZMA сжатии *.rpm пакеты занимают меньше места на DVD).
> Было бы интересно увидеть конкретные цифры установок в хэшере.

Цифры чисто по скорости сжатия/разжатия есть здесь:
http://tukaani.org/lzma/benchmarks

В хешере что-либо измерить трудно.  Во-первых, hasher создаёт
cache/chroot/chroot.cpio, то есть скорость можно измерять только
для дополнительных пактов из BuildRequires (а для базовой системы
при последовательных сборках скорость оказывается "бесплатной").
Во-вторых, собственно, сложно удержать то, что мы хотим измерить.
На tmpfs мы измеряем одно, на ext3 мы измеряем другое; в обоих случаях
буферный кеш и kswapd спутывают все карты.

> Дело в том, что gzip имеет код, который позволяет создавать архивы,
> построенные на фиксированных блоках (опция --rsyncable в утилите
> gzip), наверняка такую же настройку можно активировать и в библиотеке.
> С этими фиксированными блоками rsync очень хорошо справляется.

Увы, gzip не использует zlib (а gzdio использует zlib).  Это в
нескольких местах надо править.  И, собственно, rsync использует свою
собственную модифицированную копию zlib.  И ещё zlib есть в ядре...

К тому же на практике rsync мало используют (если я не ошибаюсь,
у нас нет ни одного rsync зеркала, зато есть несколько ftp зеркал).

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

Re: [devel] rpm: LZMA payload compression

[Alexander Bokovoy]

24 мая 2008 г. 20:37 пользователь Alexey Tourbin <at@altlinux.ru> написал:
>> Было бы интересно увидеть конкретные цифры установок в хэшере.
>
> Цифры чисто по скорости сжатия/разжатия есть здесь:
> http://tukaani.org/lzma/benchmarks
>
> В хешере что-либо измерить трудно.  Во-первых, hasher создаёт
> cache/chroot/chroot.cpio, то есть скорость можно измерять только
> для дополнительных пактов из BuildRequires (а для базовой системы
> при последовательных сборках скорость оказывается "бесплатной").
> Во-вторых, собственно, сложно удержать то, что мы хотим измерить.
> На tmpfs мы измеряем одно, на ext3 мы измеряем другое; в обоих случаях
> буферный кеш и kswapd спутывают все карты.
Это так. В таком случае может вообще не стоит рассматривать LZMA?

>> Дело в том, что gzip имеет код, который позволяет создавать архивы,
>> построенные на фиксированных блоках (опция --rsyncable в утилите
>> gzip), наверняка такую же настройку можно активировать и в библиотеке.
>> С этими фиксированными блоками rsync очень хорошо справляется.
>
> Увы, gzip не использует zlib (а gzdio использует zlib).  Это в
> нескольких местах надо править.  И, собственно, rsync использует свою
> собственную модифицированную копию zlib.  И ещё zlib есть в ядре...
Основной gzip 1.3.12 содержит в TODO план включения --rsyncable.
Аналогичный патч для zlib существует, ровно как и патчи для всех
остальных необходимых компонент, в конце концов, этот патч нужен
только для компрессии, а распаковка выполняется стандартной
процедурой. Как я уже говорил, в Debian поддержка rsyncable уже есть с
2003 или около того, в том числе благодаря работам ALT Linux Team. :-)

> К тому же на практике rsync мало используют (если я не ошибаюсь,
> у нас нет ни одного rsync зеркала, зато есть несколько ftp зеркал).
Это вопрос приоритезации. Если мы сумеем добиться внятных результатов,
то можно будет поставить rsync:// в качестве метода по умолчанию в
дистрибутивах (с возможностью перевыбора пользователями). Это позволит
сэкономить дорогой трафик в регионах и постепенно перевести
пользователей на более эффективные методы работы.

-- 
/ Alexander Bokovoy

Re: [devel] rpm: LZMA payload compression

[Alexey Tourbin]

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

On Sat, May 24, 2008 at 09:55:23PM +0400, Alexander Bokovoy wrote:
> 24 мая 2008 г. 20:37 пользователь Alexey Tourbin <at@altlinux.ru> написал:
> >> Было бы интересно увидеть конкретные цифры установок в хэшере.
> >
> > Цифры чисто по скорости сжатия/разжатия есть здесь:
> > http://tukaani.org/lzma/benchmarks
> >
> > В хешере что-либо измерить трудно.  Во-первых, hasher создаёт
> > cache/chroot/chroot.cpio, то есть скорость можно измерять только
> > для дополнительных пактов из BuildRequires (а для базовой системы
> > при последовательных сборках скорость оказывается "бесплатной").
> > Во-вторых, собственно, сложно удержать то, что мы хотим измерить.
> > На tmpfs мы измеряем одно, на ext3 мы измеряем другое; в обоих случаях
> > буферный кеш и kswapd спутывают все карты.
> Это так. В таком случае может вообще не стоит рассматривать LZMA?

Улучшение в сжатии очень значительное, зачастую в полотора раза (даже
при параметре 2, который по скорости значительно быстрее bzip2).

$ pwd
/home/at/git.alt/perl-DateTime-TimeZone

$ gear --rpm -- rpm -bs --define '_source_payload w9.gzdio'
Wrote: /home/at/RPM/SRPMS/perl-DateTime-TimeZone-0.72-alt1.src.rpm
$ du -bk /home/at/RPM/SRPMS/perl-DateTime-TimeZone-0.72-alt1.src.rpm
328     /home/at/RPM/SRPMS/perl-DateTime-TimeZone-0.72-alt1.src.rpm

$ gear --rpm -- rpm -bs --define '_source_payload w9.bzdio'
$ du -bk /home/at/RPM/SRPMS/perl-DateTime-TimeZone-0.72-alt1.src.rpm
250     /home/at/RPM/SRPMS/perl-DateTime-TimeZone-0.72-alt1.src.rpm

$ gear --rpm -- rpm -bs --define '_source_payload w2.lzdio'         
Wrote: /home/at/RPM/SRPMS/perl-DateTime-TimeZone-0.72-alt1.src.rpm
$ du -bk /home/at/RPM/SRPMS/perl-DateTime-TimeZone-0.72-alt1.src.rpm
202     /home/at/RPM/SRPMS/perl-DateTime-TimeZone-0.72-alt1.src.rpm

$ gear --rpm -- rpm -bs --define '_source_payload w9.lzdio'         
Wrote: /home/at/RPM/SRPMS/perl-DateTime-TimeZone-0.72-alt1.src.rpm
$ du -bk /home/at/RPM/SRPMS/perl-DateTime-TimeZone-0.72-alt1.src.rpm
162     /home/at/RPM/SRPMS/perl-DateTime-TimeZone-0.72-alt1.src.rpm

Huh?  Имеем 202K c lzdio против 328K с gzdio.  Если бы игра не стоила
свеч, я бы за это не взялся.  Кроме того, есть потенциал получить 162K,
но врубать по умолчанию это негуманно, потому что человеку долго времени
ждать.  Но на входе в incoming'е для "чистовой сборки" можно будет
передавать и "негуманный" параметр (на скорость разжатия он не влияет).

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

Re: [devel] [JT] rpm: LZMA payload compression

[Alexey Tourbin]

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

On Sat, May 24, 2008 at 09:55:23PM +0400, Alexander Bokovoy wrote:
> Основной gzip 1.3.12 содержит в TODO план включения --rsyncable.

Посмотрел gzip 1.3.12.

2007-02-05  Paul Eggert  <eggert@cs.ucla>
...
	* gunzip.in, zcat.in, zcmp.in, zegrep.in, zfgrep.in: New files.
...
	* gzip.c: Now requires that you compile with -DGNU_STANDARD=0 to
	get non GNU-standard behavior.  We now build with GNU-standard
	behavior by default, so that programs do not depend on the names
	of their executables.

gunzip.in:
	#!/bin/sh
	PATH=BINDIR:$PATH
	exec gzip -d "$@"

Людишки ерундой какой-то занимаются, называется GNU standard.

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

Re: [devel] [JT] rpm: LZMA payload compression

[Alexander Bokovoy]

25 мая 2008 г. 10:55 пользователь Alexey Tourbin <at@altlinux.ru> написал:
> On Sat, May 24, 2008 at 09:55:23PM +0400, Alexander Bokovoy wrote:
>> Основной gzip 1.3.12 содержит в TODO план включения --rsyncable.
>
> Посмотрел gzip 1.3.12.
>
> 2007-02-05  Paul Eggert  <eggert@cs.ucla>
> ...
>        * gunzip.in, zcat.in, zcmp.in, zegrep.in, zfgrep.in: New files.
> ...
>        * gzip.c: Now requires that you compile with -DGNU_STANDARD=0 to
>        get non GNU-standard behavior.  We now build with GNU-standard
>        behavior by default, so that programs do not depend on the names
>        of their executables.
>
> gunzip.in:
>        #!/bin/sh
>        PATH=BINDIR:$PATH
>        exec gzip -d "$@"
>
> Людишки ерундой какой-то занимаются, называется GNU standard.
Это другая проблема, давай не будем смешивать. Патч отправил?
-- 
/ Alexander Bokovoy

Re: [devel] [JT] rpm: LZMA payload compression

[Alexey Tourbin]

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

On Sun, May 25, 2008 at 11:10:13AM +0400, Alexander Bokovoy wrote:
> >        * gunzip.in, zcat.in, zcmp.in, zegrep.in, zfgrep.in: New files.
> > ...
> >        * gzip.c: Now requires that you compile with -DGNU_STANDARD=0 to
> >        get non GNU-standard behavior.  We now build with GNU-standard
> >        behavior by default, so that programs do not depend on the names
> >        of their executables.
> >
> > gunzip.in:
> >        #!/bin/sh
> >        PATH=BINDIR:$PATH
> >        exec gzip -d "$@"
> >
> > Людишки ерундой какой-то занимаются, называется GNU standard.
> Это другая проблема, давай не будем смешивать. Патч отправил?

Какой патч?

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

Re: [devel] [JT] rpm: LZMA payload compression

[Alexander Bokovoy]

25 мая 2008 г. 11:24 пользователь Alexey Tourbin <at@altlinux.ru> написал:
>> > gunzip.in:
>> >        #!/bin/sh
>> >        PATH=BINDIR:$PATH
>> >        exec gzip -d "$@"
>> >
>> > Людишки ерундой какой-то занимаются, называется GNU standard.
>> Это другая проблема, давай не будем смешивать. Патч отправил?
>
> Какой патч?
Для BINDIR :-)
-- 
/ Alexander Bokovoy

Re: [devel] rsync mirrors

[Dmitry V. Levin]

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

On Sat, May 24, 2008 at 08:37:35PM +0400, Alexey Tourbin wrote:
[...]
> К тому же на практике rsync мало используют (если я не ошибаюсь,
> у нас нет ни одного rsync зеркала, зато есть несколько ftp зеркал).

Все официальные зеркала rsync.altlinux.org::ALTLinux/
предоставляют rsync-доступ:
mirror.yandex.ru::altlinux/
ftp.linux.kiev.ua::ALTLinux/
ftp.heanet.ie::mirrors/ftp.altlinux.org/
distrib-coffee.ipsl.jussieu.fr::pub/linux/altlinux/

На эту тему даже есть жалоба:
https://bugzilla.altlinux.org/show_bug.cgi?id=15530


-- 
ldv

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

Re: [devel] rsync mirrors

[Alexey Tourbin]

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

On Sun, May 25, 2008 at 04:11:12AM +0400, Dmitry V. Levin wrote:
> On Sat, May 24, 2008 at 08:37:35PM +0400, Alexey Tourbin wrote:
> [...]
> > К тому же на практике rsync мало используют (если я не ошибаюсь,
> > у нас нет ни одного rsync зеркала, зато есть несколько ftp зеркал).
> 
> Все официальные зеркала rsync.altlinux.org::ALTLinux/
> предоставляют rsync-доступ:
> mirror.yandex.ru::altlinux/
> ftp.linux.kiev.ua::ALTLinux/
> ftp.heanet.ie::mirrors/ftp.altlinux.org/
> distrib-coffee.ipsl.jussieu.fr::pub/linux/altlinux/
> 
> На эту тему даже есть жалоба:
> https://bugzilla.altlinux.org/show_bug.cgi?id=15530

Да, я проверил apt-conf-sisyphus перед тем, как это написать.

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

[devel] gzip --rsyncable

[Alexey Tourbin]

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

On Sat, May 24, 2008 at 07:53:55PM +0400, Alexander Bokovoy wrote:
> >> 2. Насколько этот режим совместим с rsync? Сам по себе LZMA не очень
> >> приспособлен к генерации блочных структур.
> >
> > Не знаю.  В текущем виде gzdio тоже создаёт payload, который rsync
> > "не берёт".  К тому же rsync синхронизирует только файлы с одинаковыми
> > названиями (точнее, у rsync есть опция -y, но я не уверен, что она
> > всегда хорошо работает).
> Дело в том, что gzip имеет код, который позволяет создавать архивы,
> построенные на фиксированных блоках (опция --rsyncable в утилите
> gzip), наверняка такую же настройку можно активировать и в библиотеке.
> С этими фиксированными блоками rsync очень хорошо справляется.

А будет ли 'gzip --rsyncable' что-то давать для rpm пакетов?

Я локально пересобрал gzip с патчем
http://www.samba.org/netfilter/diary/gzip.rsync.patch

Проведём эксперимент: нужно синхронизировать предыдущую сборку
glibc-core (которая есть у меня на локальной машине) с текущей
(на удалённой машине с сизифом).

На удалённой машине выполняю действие:
$ rpm2cpio /ALT/Sisyphus/files/x86_64/RPMS/glibc-core-2.5.1-alt5.x86_64.rpm |./gzip -9nf --rsyncable >cpio-alt5.gz
$ du -bk cpio-alt5.gz
1455    cpio-alt5.gz
$ 

На локальной машине выполняю действие:
$ rpm2cpio /ALT/Sisyphus/files/x86_64/RPMS/glibc-core-2.5.1-alt4.x86_64.rpm |./gzip -9nf --rsyncable >cpio-alt4.gz                                            
$ du -bk cpio-alt4.gz
1455    cpio-alt4.gz
$

Теперь в порядке эксперимента нужно просинхронизировать cpio-alt5.gz
с удалённой машины в cpio-alt4.gz на локальной машине.

На локальной машине выполняется действие:
$ rsync -va armor:cpio-alt5.gz cpio-alt4.gz
receiving incremental file list
cpio-alt5.gz

sent 7380 bytes  received 1483907 bytes  28957.03 bytes/sec
total size is 1489685  speedup is 1.00
$

Ничего не получилось, я полностью скачал rsyncable сpio.gz.
Что я сделал не так?  Изменения glibc-core между 2.5.1-alt4
и 2.5.1-alt5 только в spec-файле.

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

Re: [devel] gzip --rsyncable

[Alexander Bokovoy]

25 мая 2008 г. 11:54 пользователь Alexey Tourbin <at@altlinux.ru> написал:
> sent 7380 bytes  received 1483907 bytes  28957.03 bytes/sec
> total size is 1489685  speedup is 1.00
> $
>
> Ничего не получилось, я полностью скачал rsyncable сpio.gz.
> Что я сделал не так?  Изменения glibc-core между 2.5.1-alt4
> и 2.5.1-alt5 только в spec-файле.
А какой результат в этом случае дает использование опции -y (--fuzzy)
в rsync? Только не надо указывать файл на принимающей стороне, он сам
его найдет.
-- 
/ Alexander Bokovoy

Re: [devel] gzip --rsyncable

[Alexey Tourbin]

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

On Sun, May 25, 2008 at 12:08:01PM +0400, Alexander Bokovoy wrote:
> 25 мая 2008 г. 11:54 пользователь Alexey Tourbin <at@altlinux.ru> написал:
> > sent 7380 bytes  received 1483907 bytes  28957.03 bytes/sec
> > total size is 1489685  speedup is 1.00
> > $
> >
> > Ничего не получилось, я полностью скачал rsyncable сpio.gz.
> > Что я сделал не так?  Изменения glibc-core между 2.5.1-alt4
> > и 2.5.1-alt5 только в spec-файле.
> А какой результат в этом случае дает использование опции -y (--fuzzy)
> в rsync? Только не надо указывать файл на принимающей стороне, он сам
> его найдет.

Насколько я знаю, опция -y имеет смысл только при синхронизации
каталогов.  Когда destination файла не существует, опция -y подбирает
"исходный" destination файл в том же каталоге с "похожим названием".
Какая метрика там используется я не знаю.

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

Re: [devel] gzip --rsyncable

[Alexander Bokovoy]

25 мая 2008 г. 12:18 пользователь Alexey Tourbin <at@altlinux.ru> написал:
> On Sun, May 25, 2008 at 12:08:01PM +0400, Alexander Bokovoy wrote:
>> 25 мая 2008 г. 11:54 пользователь Alexey Tourbin <at@altlinux.ru> написал:
>> > sent 7380 bytes  received 1483907 bytes  28957.03 bytes/sec
>> > total size is 1489685  speedup is 1.00
>> > $
>> >
>> > Ничего не получилось, я полностью скачал rsyncable сpio.gz.
>> > Что я сделал не так?  Изменения glibc-core между 2.5.1-alt4
>> > и 2.5.1-alt5 только в spec-файле.
>> А какой результат в этом случае дает использование опции -y (--fuzzy)
>> в rsync? Только не надо указывать файл на принимающей стороне, он сам
>> его найдет.
>
> Насколько я знаю, опция -y имеет смысл только при синхронизации
> каталогов.  Когда destination файла не существует, опция -y подбирает
> "исходный" destination файл в том же каталоге с "похожим названием".
> Какая метрика там используется я не знаю.
Я тебе отвечу письмом Jeff Johnson, который этот вопрос уже исследовал
три года назад:
https://lists.dulug.duke.edu/pipermail/rpm-devel/2004-December/000154.html

Патч, который брал ты, он отличается от рекомендуемого
http://ozlabs.org/~rusty/gzip.rsync.patch2, на который ссылаются как
Джефф, так и Эгмонт.

-- 
/ Alexander Bokovoy

Re: [devel] gzip --rsyncable

[Alexander Bokovoy]

25 мая 2008 г. 12:31 пользователь Alexander Bokovoy <ab@altlinux.org> написал:
> 25 мая 2008 г. 12:18 пользователь Alexey Tourbin <at@altlinux.ru> написал:
>> On Sun, May 25, 2008 at 12:08:01PM +0400, Alexander Bokovoy wrote:
>>> 25 мая 2008 г. 11:54 пользователь Alexey Tourbin <at@altlinux.ru> написал:
>>> > sent 7380 bytes  received 1483907 bytes  28957.03 bytes/sec
>>> > total size is 1489685  speedup is 1.00
>>> > $
>>> >
>>> > Ничего не получилось, я полностью скачал rsyncable сpio.gz.
>>> > Что я сделал не так?  Изменения glibc-core между 2.5.1-alt4
>>> > и 2.5.1-alt5 только в spec-файле.
>>> А какой результат в этом случае дает использование опции -y (--fuzzy)
>>> в rsync? Только не надо указывать файл на принимающей стороне, он сам
>>> его найдет.
>>
>> Насколько я знаю, опция -y имеет смысл только при синхронизации
>> каталогов.  Когда destination файла не существует, опция -y подбирает
>> "исходный" destination файл в том же каталоге с "похожим названием".
>> Какая метрика там используется я не знаю.
> Я тебе отвечу письмом Jeff Johnson, который этот вопрос уже исследовал
> три года назад:
> https://lists.dulug.duke.edu/pipermail/rpm-devel/2004-December/000154.html
>
> Патч, который брал ты, он отличается от рекомендуемого
> http://ozlabs.org/~rusty/gzip.rsync.patch2, на который ссылаются как
> Джефф, так и Эгмонт.
Вот еще одна статья, которая может представлять интерес для
оптимизации работы с репозитариями, с гораздо большим практическим
результатом. Это работа Колин Фиппса по созданию zsync, использующего
тот же механизм, что и rsync, но выполняющего расчеты циклической
контрольной суммы на стороне клиента. Транспорт apt, построенный
поверх zsync (в том числе и с тем же патчем gzip.rsync.patch2)
позволит, например, http-зеркалу отдавать эффективно пакеты, используя
предварительно вычисленные суммы для блоков в виде метаданных вне
зависимости от каждого клиента (при генерации репозитория). Это
позволит увеличить скорость работы зеркала и облегчить нагрузку на
него (нет необходимости вычислять контрольные суммы каждый раз, когда
клиент обращается к зеркалу).
http://zsync.moria.org.uk/paper/paper.html

Вариант с zsync хорош тем, что позволяет делать зеркала с минимальным
знанием особенностей оптимизационных механизмов -- достаточно сервера
HTTP/1.0 или HTTP/1.1 и метаданных.
-- 
/ Alexander Bokovoy

Re: [devel] gzip --rsyncable

[Alexey Tourbin]

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

On Sun, May 25, 2008 at 12:31:24PM +0400, Alexander Bokovoy wrote:
> Патч, который брал ты, он отличается от рекомендуемого
> http://ozlabs.org/~rusty/gzip.rsync.patch2, на который ссылаются как
> Джефф, так и Эгмонт.

Этот патч немножко не прикладыватся к нашему гзипу.
Но, действительно, с ним эффект есть.

$ rsync -va armor:cpio-alt5.gz cpio-alt4.gz
receiving incremental file list
cpio-alt5.gz

sent 7392 bytes  received 117470 bytes  19209.54 bytes/sec
total size is 1500796  speedup is 12.02
$ 

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

[devel] rsync_roll

[Alexey Tourbin]

[-- Attachment #1.1: Type: text/plain, Size: 2574 bytes --]

On Sun, May 25, 2008 at 12:31:24PM +0400, Alexander Bokovoy wrote:
> Патч, который брал ты, он отличается от рекомендуемого
> http://ozlabs.org/~rusty/gzip.rsync.patch2, на который ссылаются как
> Джефф, так и Эгмонт.

Что делает этот патч?  Почему "это работает"?
Прошу подсказать, правильно ли я понимаю это дело или нет.

Этот патч оперирует на входном (несжатом) потоке байтов
|--------------------------------------------------------->

Вычисляется "контрольная сумма" (с переполнением) "окна"
размером RSYNC_WIN байтов входного потока.

|--------------------------------------------------------->
   |___________|
     RSYNC_WIN

При добавлении каждого нового байта окно "сдвигается" и вычисляется
новая сумма.

|--------------------------------------------------------->
    -|__________+|
       RSYNC_WIN

Особенность вычисления этой суммы состоит в том, что достаточно
вычесть старый "выбывший" элемент (слева, отмечен знаком минус)
и добавить новый элемент (отмечен знаком плюс).

Когда сумма принимает определённое значение (а именно, когда
sum % RSYNC_WIN == 0) то в конце окна принимается решение
"сборосить блок" и заново инициализировать процедуру сжатия.

|--------------------------------------------------------->
     |_____0_____|
       RSYNC_WIN  \
       		   `reset compression here!
                
Это означает, что в этой точке как бы начинается "новый файл",
который gzip будет жать отдельно; если в двух разных входных
потоках в точке обнуления суммы несжатые данные идут одинаковые,
то и сжатые данные пойдут одинаковые.

Я всё равно плохо понимаю, почему "это работает", то есть как это
способствует повышению rsyncability.

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

Чтобы понять, как работет этот код, мне нужно пере-реализовать его
без привязки к гзипу.  Я приложил файл rsyncable.с, в котором попытался
воспроизвести то, о чём идёт речь.

$ ./rsyncable </etc/info-dir
sync at 4920
sync at 19949
sync at 24300
sync at 31782
sync at 44390
sync at 50260
sync at 68705
sync at 80677
sync at 85097
$ du -bk /etc/info-dir
84      /etc/info-dir
$ 

Из этого видно, что на самом деле размер блока в данном случае
получается примерно 8K (9 синков = 10 блоков на 84Кб), а не 4,
как я ожидал.  В чём тут дело?

[-- Attachment #1.2: rsyncable.c --]
[-- Type: text/plain, Size: 909 bytes --]

#include <stdint.h>
#include <stdbool.h>

#define RSYNC_WIN 4096

struct rsync_state {
	uint64_t n;			/* number of elements in the window */
	uint64_t sum;			/* current sum */
	unsigned char win[RSYNC_WIN];	/* window elements */
};

static inline
bool rsync_next(struct rsync_state *s, unsigned char c)
{
	if (s->n < RSYNC_WIN) {		/* not enough elements */
		s->sum += c;		/* update the sum */
		s->win[s->n++] = c;	/* remember the element */
		return false;		/* no match */
	}
	int i = s->n++ % RSYNC_WIN;	/* wrap up */
	s->sum -= s->win[i];		/* move the window on */
	s->sum += c;
	s->win[i] = c;
	if (s->sum % RSYNC_WIN == 0) {	/* match */
		s->n = 0;		/* reset */
		s->sum = 0;
		return true;
	}
	return false;
}

#include <stdio.h>

int main()
{
	struct rsync_state rs = { 0, 0 };
	int c;
	while ((c = getc(stdin)) != EOF)
		if (rsync_next(&rs, c))
			printf("sync at %ld\n", ftell(stdin));
	return 0;
}

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

Re: [devel] rsync_roll

[Alexander Bokovoy]

25 мая 2008 г. 22:30 пользователь Alexey Tourbin <at@altlinux.ru> написал:
> On Sun, May 25, 2008 at 12:31:24PM +0400, Alexander Bokovoy wrote:
>> Патч, который брал ты, он отличается от рекомендуемого
>> http://ozlabs.org/~rusty/gzip.rsync.patch2, на который ссылаются как
>> Джефф, так и Эгмонт.
>
> Что делает этот патч?  Почему "это работает"?
> Прошу подсказать, правильно ли я понимаю это дело или нет.
Я пока слабо соображаю (сваливаюсь в грипп с отвратительной погодой),
но хочу заметить, что в ранних версиях патча размер окна был в 8Кб,
однако практика его использования показала, что баланс достигается при
размере окна в 4Кб. Как отметил Джефф, это не самый оптимальный
вариант, но зато самый удовлетворительный с практической точки зрения.
У автора zsync примерно такие же эмпирические результаты получились.


-- 
/ Alexander Bokovoy

Re: [devel] rsync_roll

[Alexander Myltsev]

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.

Re: [devel] rsync_roll

[Alexey Tourbin]

[-- 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 --]

Re: [devel] rsync_roll

[Alexey Tourbin]

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

On Mon, May 26, 2008 at 11:15:53AM +0400, Alexey Tourbin wrote:
> 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-
>         ^     ^   ^     ^  ^   ^   ^    ^

Кажется, я начинаю понимать простые вещи.  Значение суммы зависит только
от последних 4096 байтов.  Значит, как только 4096 байтов в DATA-DATA-
совпали, то процесс "сходится" и ближайшее обнуление суммы будет
синхронным.

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

Re: [devel] gzip --rsyncable

[Led]

Sunday, 25 May 2008 10:54:04 Alexey Tourbin написав:
> On Sat, May 24, 2008 at 07:53:55PM +0400, Alexander Bokovoy wrote:
> > >> 2. Насколько этот режим совместим с rsync? Сам по себе LZMA не очень
> > >> приспособлен к генерации блочных структур.
> > >
> > > Не знаю.  В текущем виде gzdio тоже создаёт payload, который rsync
> > > "не берёт".  К тому же rsync синхронизирует только файлы с одинаковыми
> > > названиями (точнее, у rsync есть опция -y, но я не уверен, что она
> > > всегда хорошо работает).
> >
> > Дело в том, что gzip имеет код, который позволяет создавать архивы,
> > построенные на фиксированных блоках (опция --rsyncable в утилите
> > gzip), наверняка такую же настройку можно активировать и в библиотеке.
> > С этими фиксированными блоками rsync очень хорошо справляется.
>
> А будет ли 'gzip --rsyncable' что-то давать для rpm пакетов?
>
> Я локально пересобрал gzip с патчем
> http://www.samba.org/netfilter/diary/gzip.rsync.patch
>
> Проведём эксперимент: нужно синхронизировать предыдущую сборку
> glibc-core (которая есть у меня на локальной машине) с текущей
> (на удалённой машине с сизифом).
>
> На удалённой машине выполняю действие:
> $ rpm2cpio /ALT/Sisyphus/files/x86_64/RPMS/glibc-core-2.5.1-alt5.x86_64.rpm
> |./gzip -9nf --rsyncable >cpio-alt5.gz $ du -bk cpio-alt5.gz
> 1455    cpio-alt5.gz
> $
>
> На локальной машине выполняю действие:
> $ rpm2cpio /ALT/Sisyphus/files/x86_64/RPMS/glibc-core-2.5.1-alt4.x86_64.rpm
> |./gzip -9nf --rsyncable >cpio-alt4.gz $ du -bk cpio-alt4.gz
> 1455    cpio-alt4.gz
> $
>
> Теперь в порядке эксперимента нужно просинхронизировать cpio-alt5.gz
> с удалённой машины в cpio-alt4.gz на локальной машине.
>
> На локальной машине выполняется действие:
> $ rsync -va armor:cpio-alt5.gz cpio-alt4.gz
> receiving incremental file list
> cpio-alt5.gz
>
> sent 7380 bytes  received 1483907 bytes  28957.03 bytes/sec
> total size is 1489685  speedup is 1.00
> $
>
> Ничего не получилось, я полностью скачал rsyncable сpio.gz.
> Что я сделал не так?  Изменения glibc-core между 2.5.1-alt4
> и 2.5.1-alt5 только в spec-файле.

А если явно указать
rsync --block-size=100k ...
?

-- 
Led

Re: [devel] gzip --rsyncable

[Alexey Tourbin]

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

On Sun, May 25, 2008 at 11:54:04AM +0400, Alexey Tourbin wrote:
> На локальной машине выполняется действие:
> $ rsync -va armor:cpio-alt5.gz cpio-alt4.gz
> receiving incremental file list
> cpio-alt5.gz
> 
> sent 7380 bytes  received 1483907 bytes  28957.03 bytes/sec
> total size is 1489685  speedup is 1.00
> $

Для сравнения: разжатые cpio rsync действительно "берёт".

$ rsync -va armor:cpio-alt5 cpio-alt4
receiving incremental file list
cpio-alt5

sent 10902 bytes  received 55919 bytes  133642.00 bytes/sec
total size is 3260708  speedup is 48.80
$ 

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