[devel] comprehensive rsyncability test

[Alexey Tourbin]

Перейду к инетпретации результатов тестирования.

1) Численный аспект тестирования отвечает на ворос, какой объем нужно
скачать, чтобы синхронизировать новые x86_64 пакеты за один месяц.

$ perl -le 'print "|".("-"x(2434968/2434968*78))."|"'       
|------------------------------------------------------------------------------|
таков общий объем новых файлов, пожатых гзипом.

$ perl -le 'print "|".("-"x(1643033/2434968*78))."|"'
|----------------------------------------------------|
столько скачал бы rsync, если новые И старые файлы пожать в rsyncable deflate.

$ perl -le 'print "|".("-"x(1960275/2434968*78))."|"'
|--------------------------------------------------------------|
столько пришлось бы скачать, если новые файлы пожать с помощью 'lzma -2'.

$ perl -le 'print "|".("-"x(1819361/2434968*78))."|"'
|----------------------------------------------------------|
столько пришлось бы скачать, если новые файлы пожать с помощью 'lzma -5'.

Таким образом, численно rsync сохраняет преимущество, но наглядная
интерпретация показывает, что LZMA перекрывает большую часть выгоды,
которую даёт rsync, так что сравнительное преимущество rsync оказывается
небольшим.

2) Рассмотренный численный аспект проблемы -- не единственный, хотя
и наиболее важный.  Следует спрашивать не только "сколько нужно
скачать", но и учитывать также, "сколько это в конечном счёте будет
занимать места на диске".  Если правомерно считать вопрос storage
следующим по актуальности после вопроса trnasfer, то LZMA здесь
показывает серьёзное преимущество:
|------------------------------------------------------------------------------|
|----------------------------------------------------------|

3) Конечно, есть ещё один аспект проблемы.  LZMA даёт прямое
преимущество, потому что уменьшение размера файла напрямую влияет
на объем для скачивания; а rsyncability даёт только косвенное/
гипотетическое преимущество.  Чтобы преимущество rsync могло
реализоваться, должны быть выполнены три условия: у пользователя есть
старые файлы; старые файлы пожаты в rsyncable deflate; и пользователь
правильно организовал процесс синхронизации.

Этот аспект проблемы трудно оценить численно, но он является достаточно
важным.

Таким образом, я считаю, что в вопросе "rsyncable deflate vs LZMA"
ни один из вариантов не имеет решающих преимуществ.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 197 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20080601/3b62a129/attachment-0002.bin>