[devel] comprehensive rsyncability test

[devel] comprehensive rsyncability test

[Alexey Tourbin]

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

Предварительное тестирование rsyncable gzdio показало, что эффект
от rsyncable deflate есть, и лучше всего он проявляется при
незначительном изменении пакетов; кроме того, пакет должен содержать
достаточно большие файлы (если пакет целиком состоит из маленьких
файлов, то rsyncability резко падает).

Но одиночные тесты не выявляют "реального положения вещей"; требуется
более широкое тестирование с привлечением "реальных данных" за некоторый
промежуток времени.

Предлагаю протестировать rsyncability двух каталогов:
/ALT/archive/Sisyphus/2008/03/01/files/x86_64/RPMS
/ALT/archive/Sisyphus/2008/04/01/files/x86_64/RPMS

Методика тестирования следующая:
1) Из каталогов парами выбираются файлы, у которых совпадает
имя пакета %{NAME}, но при этом не совпадает имя файла
%name-%version-%release.x86_64.rpm.
2) Для каждой пары пакетов извлекается cpio архив и перепаковывается
с помощью rsyncable gzdio из нового rpmio.
3) Отсекаются маленькие пакеты: оба перепакованных архива должны быть
больше 32K.
4) Запускается rsync, который диагностирует степень "совпадения" двух
перепакованных архивов.

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

файл-1   размер-1   файл-2   размер-2   послано   скочено   speedup
------   --------   ------   --------   -------   -------   -------

Последние три поля из диагностики rsync.  Размеры округляются
до килобайтов.

$ wc -l <rsyncability.txt
1360
$

Всего мы рассматриваем 1360 штук x86_64 пакетов, которые обновились
с 1 марта по 1 апреля 2008 года.

$ awk '$NF>2' rsyncability.txt |wc -l
211
$

Из них достаточно большим значением speedup (синхронизация вдвое
быстрее, чем простое скачивание) обладают 211 пакетов.

$ sum() { perl -MList::Util=sum -ln0 -e 'print sum split'; }
$ cut -f4 rsyncability.txt |sum
2433627
$

Общий размер новых пакетов 2.32G.

$ cut -f6 rsyncability.txt |sum
1643033
$

При этом rsync скачал 1.57G.

$ cut -f5 rsyncability.txt |sum    
14017
$

Нужно также понимать, что rsync не только что-то скачал,
но и послал 13.7M (оверхед протокола при поиске совпадающих кусков;
опция --block-size здесь влияет).

ТАКИМ ОБРАЗОМ, я считаю, что эта ситуация в какой-то степени отражает
"реальное положение вещей".  А именно, если бы мы просто скачивали
"новые файлы за март", то мы скачали бы 2.32G.  Если же мы
синхронизировали "новые файлы за март" со "старыми домартовскими
файлами", то мы скачали бы где-то 1.6G (напоминаю, что совсем маленькие
пакеты исключены из рассмотрения).  Этот расчёт сделан в предположении,
что как старые предмартовские файлы, так и новые файлы за март УЖЕ
запакованы при помощи rsyncable gzdio.

Вот код скрита (gzdio.c и rsync-shell были в одном из предыдущих писем,
packages из пакета qa-robot).

test-dirs:
#!/bin/sh -efu
packages "$1" >pkg1
packages "$2" >pkg2
join -t$'\t' -j 1 -o '0 1.3 2.3' pkg1 pkg2 |awk -F'\t' '$2!=$3' >pkg12
while read -r pkg f1 f2; do
	rpm2cpio "$1/$f1" |./gzdio >cpio1.gz
	rpm2cpio "$2/$f2" |./gzdio >cpio2.gz
	s1=$(du -b cpio1.gz |awk '{print int($1/1024+0.5)}')
	s2=$(du -b cpio2.gz |awk '{print int($1/1024+0.5)}')
	[ "$s1" -gt 32 ] && [ "$s2" -gt 32 ] || continue
	rsync --block-size 1024 -v -e ./rsync-shell foo:cpio2.gz cpio1.gz >out
	sent=$(awk '$1=="sent"{print int($2/1024+.5)}' out)
	received=$(awk '$4=="received"{print int($5/1024+.5)}' out)
	speedup=$(awk '$5=="speedup"{print$7}' out)
	echo $f1$'\t'$s1$'\t'$f2$'\t'$s2$'\t'$sent$'\t'$received$'\t'$speedup
done <pkg12

[-- Attachment #1.2: rsyncability.txt.bz2 --]
[-- Type: application/x-bzip2, Size: 25050 bytes --]

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

Re: [devel] comprehensive rsyncability test

[Dmitry V. Levin]

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

On Sat, May 31, 2008 at 10:58:47PM +0400, Alexey Tourbin wrote:
> Предварительное тестирование rsyncable gzdio показало, что эффект
> от rsyncable deflate есть, и лучше всего он проявляется при
> незначительном изменении пакетов; кроме того, пакет должен содержать
> достаточно большие файлы (если пакет целиком состоит из маленьких
> файлов, то rsyncability резко падает).
> 
> Но одиночные тесты не выявляют "реального положения вещей"; требуется
> более широкое тестирование с привлечением "реальных данных" за некоторый
> промежуток времени.
> 
> Предлагаю протестировать rsyncability двух каталогов:
> /ALT/archive/Sisyphus/2008/03/01/files/x86_64/RPMS
> /ALT/archive/Sisyphus/2008/04/01/files/x86_64/RPMS
> 
> Методика тестирования следующая:
> 1) Из каталогов парами выбираются файлы, у которых совпадает
> имя пакета %{NAME}, но при этом не совпадает имя файла
> %name-%version-%release.x86_64.rpm.
> 2) Для каждой пары пакетов извлекается cpio архив и перепаковывается
> с помощью rsyncable gzdio из нового rpmio.
> 3) Отсекаются маленькие пакеты: оба перепакованных архива должны быть
> больше 32K.
> 4) Запускается rsync, который диагностирует степень "совпадения" двух
> перепакованных архивов.

Тогда, наверное, надо сравнить ещё и размер rsyncable deflate, нынешний
не-rsyncable deflate и lzma для этих двух групп пакетов.

> ТАКИМ ОБРАЗОМ, я считаю, что эта ситуация в какой-то степени отражает
> "реальное положение вещей".  А именно, если бы мы просто скачивали
> "новые файлы за март", то мы скачали бы 2.32G.  Если же мы
> синхронизировали "новые файлы за март" со "старыми домартовскими
> файлами", то мы скачали бы где-то 1.6G (напоминаю, что совсем маленькие
> пакеты исключены из рассмотрения).  Этот расчёт сделан в предположении,
> что как старые предмартовские файлы, так и новые файлы за март УЖЕ
> запакованы при помощи rsyncable gzdio.


-- 
ldv

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

Re: [devel] comprehensive rsyncability test

[Alexey Tourbin]

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

On Sat, May 31, 2008 at 11:44:52PM +0400, Dmitry V. Levin wrote:
> On Sat, May 31, 2008 at 10:58:47PM +0400, Alexey Tourbin wrote:
> > Предварительное тестирование rsyncable gzdio показало, что эффект
> > от rsyncable deflate есть, и лучше всего он проявляется при
> > незначительном изменении пакетов; кроме того, пакет должен содержать
> > достаточно большие файлы (если пакет целиком состоит из маленьких
> > файлов, то rsyncability резко падает).
> > 
> > Но одиночные тесты не выявляют "реального положения вещей"; требуется
> > более широкое тестирование с привлечением "реальных данных" за некоторый
> > промежуток времени.
> > 
> > Предлагаю протестировать rsyncability двух каталогов:
> > /ALT/archive/Sisyphus/2008/03/01/files/x86_64/RPMS
> > /ALT/archive/Sisyphus/2008/04/01/files/x86_64/RPMS
> > 
> > Методика тестирования следующая:
> > 1) Из каталогов парами выбираются файлы, у которых совпадает
> > имя пакета %{NAME}, но при этом не совпадает имя файла
> > %name-%version-%release.x86_64.rpm.
> > 2) Для каждой пары пакетов извлекается cpio архив и перепаковывается
> > с помощью rsyncable gzdio из нового rpmio.
> > 3) Отсекаются маленькие пакеты: оба перепакованных архива должны быть
> > больше 32K.
> > 4) Запускается rsync, который диагностирует степень "совпадения" двух
> > перепакованных архивов.
> 
> Тогда, наверное, надо сравнить ещё и размер rsyncable deflate, нынешний
> не-rsyncable deflate и lzma для этих двух групп пакетов.

Что касается rsyncable deflate vs common deflate, то ответ простой:
коэффициент сжатия в среднем не изменяется.

Я прицепил таблицу deflate.txt:

файл-2   gzip-9-размер   rsyncable-gzdio-размер
------   -------------   ----------------------

$ cut -f2 deflate.txt |sum 
2434968
$ cut -f3 deflate.txt |sum
2437193
$ perl -le 'print 2437193/2434968*100'
100.091376970868
$ 

Разница в сжатии менее одной десятой процента, что при 1360 файлах
можно в значительной степени списать на статистическую погрешность.

Сжатие дело тонкое!


#!/bin/sh -efu
packages "$1" >pkg1
packages "$2" >pkg2
join -t$'\t' -j 1 -o '0 1.3 2.3' pkg1 pkg2 |awk -F'\t' '$2!=$3' >pkg12
while read -r pkg f1 f2; do
        rpm2cpio "$2/$f2" |gzip -9 >cpio1.gz
        rpm2cpio "$2/$f2" |./gzdio >cpio2.gz
        s1=$(du -b cpio1.gz |awk '{print int($1/1024+0.5)}')
        s2=$(du -b cpio2.gz |awk '{print int($1/1024+0.5)}')
        [ "$s1" -gt 32 ] && [ "$s2" -gt 32 ] || continue
        echo $f2$'\t'$s1$'\t'$s2
done <pkg12

[-- Attachment #1.2: deflate.txt.gz --]
[-- Type: application/x-gzip, Size: 17087 bytes --]

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

Re: [devel] comprehensive rsyncability test

[Dmitry V. Levin]

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

On Sun, Jun 01, 2008 at 01:32:39AM +0400, Alexey Tourbin wrote:
[...]
> Что касается rsyncable deflate vs common deflate, то ответ простой:
> коэффициент сжатия в среднем не изменяется.

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


-- 
ldv

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

Re: [devel] comprehensive rsyncability test

[Alexey Tourbin]

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

On Sun, Jun 01, 2008 at 01:57:22AM +0400, Dmitry V. Levin wrote:
> On Sun, Jun 01, 2008 at 01:32:39AM +0400, Alexey Tourbin wrote:
> [...]
> > Что касается rsyncable deflate vs common deflate, то ответ простой:
> > коэффициент сжатия в среднем не изменяется.
> 
> Я ожидал, что rsyncable deflate не может показать лучший коэффициент
> сжатия, чем обычный deflate.  Однако в приложенном файле довольно много
> случаев, когда rsyncable deflate сильнее...

Это связано с cpio hints -- дело в том, что мы пытаемся начинать новый
deflate блок на границе файлов, когда начинается новый файл.

Рассмотрим пример.  В cpio подряд идут ELF файл размером 8K и дальше
текстовый файл размером 8K.  "Слепое" разбиение на блоки в deflate этого
не понимает, в результате ELF и текстовый файл попадут в один и тот же
deflate блок.

Дальше надо знать, что такое частотное кодирование и Huffman tree.
В ELF файле встречаются все поряд символы с достаточно равномерными
вероятностями; а в текстовом файле встречаются только ASCII буквы,
и вероятности появления букв (в английском тексте) хорошо известны
(они неодинаковые).  В начале каждого deflate блока идёт Huffman tree,
и если мы делаем sync на границе binary file/text file, то последующий
текстовый кусок сожмётся гораздо более эффективно.

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

Re: [devel] comprehensive rsyncability test

[Dmitry V. Levin]

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

On Sun, Jun 01, 2008 at 02:14:23AM +0400, Alexey Tourbin wrote:
> On Sun, Jun 01, 2008 at 01:57:22AM +0400, Dmitry V. Levin wrote:
> > On Sun, Jun 01, 2008 at 01:32:39AM +0400, Alexey Tourbin wrote:
> > [...]
> > > Что касается rsyncable deflate vs common deflate, то ответ простой:
> > > коэффициент сжатия в среднем не изменяется.
> > 
> > Я ожидал, что rsyncable deflate не может показать лучший коэффициент
> > сжатия, чем обычный deflate.  Однако в приложенном файле довольно много
> > случаев, когда rsyncable deflate сильнее...
> 
> Это связано с cpio hints -- дело в том, что мы пытаемся начинать новый
> deflate блок на границе файлов, когда начинается новый файл.

А, тогда понятно, откуда это берётся.  В других реализациях rsyncable
deflate не использовал этого "естественного" разбиения, и результат,
естественно, был хуже.


-- 
ldv

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

Re: [devel] comprehensive rsyncability test

[Alexey Tourbin]

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

On Sun, Jun 01, 2008 at 02:26:33AM +0400, Dmitry V. Levin wrote:
> > > Я ожидал, что rsyncable deflate не может показать лучший коэффициент
> > > сжатия, чем обычный deflate.  Однако в приложенном файле довольно много
> > > случаев, когда rsyncable deflate сильнее...
> > 
> > Это связано с cpio hints -- дело в том, что мы пытаемся начинать новый
> > deflate блок на границе файлов, когда начинается новый файл.
> 
> А, тогда понятно, откуда это берётся.  В других реализациях rsyncable
> deflate не использовал этого "естественного" разбиения, и результат,
> естественно, был хуже.

То есть более частое разбиение на блоки может компенсироваться более
маленьким Huffman tree и более оптимальным частотным кодированием внутри
блока.  Но для этого требуется дополнительная информация.

Вместе с тем, если файл (внутри cpio) достаточно большой, то в пределах
файла будет работать rsync_next алгоритм, так что он сможет отловить
совпадающие куски внутри этого файла (rsync_next делает блок в среднем
раз в 8K).  То есть, в частности, для src.rpm сохраняется blind
rsyncability.

Кстати, я подумывал над тем, чтобы сделать tar hints, но ничего хорошего
(и при этом достаточно простого) не придумалось.

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

Re: [devel] comprehensive rsyncability test

[Alexey Tourbin]

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

On Sat, May 31, 2008 at 11:44:52PM +0400, Dmitry V. Levin wrote:
> On Sat, May 31, 2008 at 10:58:47PM +0400, Alexey Tourbin wrote:
> > Предварительное тестирование rsyncable gzdio показало, что эффект
> > от rsyncable deflate есть, и лучше всего он проявляется при
> > незначительном изменении пакетов; кроме того, пакет должен содержать
> > достаточно большие файлы (если пакет целиком состоит из маленьких
> > файлов, то rsyncability резко падает).
> > 
> > Но одиночные тесты не выявляют "реального положения вещей"; требуется
> > более широкое тестирование с привлечением "реальных данных" за некоторый
> > промежуток времени.
> > 
> > Предлагаю протестировать rsyncability двух каталогов:
> > /ALT/archive/Sisyphus/2008/03/01/files/x86_64/RPMS
> > /ALT/archive/Sisyphus/2008/04/01/files/x86_64/RPMS
> > 
> > Методика тестирования следующая:
> > 1) Из каталогов парами выбираются файлы, у которых совпадает
> > имя пакета %{NAME}, но при этом не совпадает имя файла
> > %name-%version-%release.x86_64.rpm.
> > 2) Для каждой пары пакетов извлекается cpio архив и перепаковывается
> > с помощью rsyncable gzdio из нового rpmio.
> > 3) Отсекаются маленькие пакеты: оба перепакованных архива должны быть
> > больше 32K.
> > 4) Запускается rsync, который диагностирует степень "совпадения" двух
> > перепакованных архивов.
> 
> Тогда, наверное, надо сравнить ещё и размер rsyncable deflate, нынешний
> не-rsyncable deflate и lzma для этих двух групп пакетов.

Далее я прицепил таблицу

файл-2   gzdio-размер   lzdio(2)-размер   lzma-5-размер
------   ------------   ---------------   -------------

$ cut -f2 lzma.txt |sum                                     
2433627
$

Общий размер новых файлов, перепакованных с помощью rsyncable deflate,
прежний -- 2.32G.

$ cut -f3 lzma.txt |sum
1960275
$ cut -f4 lzma.txt |sum
1819361
$ 

Если те же самые файлы сжать с помощью 'lzma -2' или 'lzma -5',
то получим 1.87G и 1.73G соответственно.  Напомню, что при
синхронизации rsync скачал 1.57G.  Несколько точнее, разница
между 1.57G и 1.73G в данном случае 172M.


#!/bin/sh -efu
packages "$1" >pkg1
packages "$2" >pkg2
join -t$'\t' -j 1 -o '0 1.3 2.3' pkg1 pkg2 |awk -F'\t' '$2!=$3' >pkg12
while read -r pkg f1 f2; do
        rpm2cpio "$1/$f1" |./gzdio >cpio1.gz
        rpm2cpio "$2/$f2" |./gzdio >cpio2.gz
        s1=$(du -b cpio1.gz |awk '{print int($1/1024+0.5)}')
        s2=$(du -b cpio2.gz |awk '{print int($1/1024+0.5)}')
        [ "$s1" -gt 32 ] && [ "$s2" -gt 32 ] || continue
        rpm2cpio "$2/$f2" |./lzdio >cpio2.lz-2
        rpm2cpio "$2/$f2" |./lzma -5 >cpio2.lz-5
        s3=$(du -b cpio2.lz-2 |awk '{print int($1/1024+0.5)}')
        s4=$(du -b cpio2.lz-5 |awk '{print int($1/1024+0.5)}')
        echo $f2$'\t'$s2$'\t'$s3$'\t'$s4
done <pkg12

Здесь программа lzdio.c такая же, как gzdio.c, только в ней вместо
"w9.gzdio" написано "w2.lzdio".

[-- Attachment #1.2: lzma.txt.gz --]
[-- Type: application/x-gzip, Size: 19681 bytes --]

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

Re: [devel] comprehensive rsyncability test

[Alexey Tourbin]

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

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

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"
ни один из вариантов не имеет решающих преимуществ.

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

Re: [devel] comprehensive rsyncability test

[Anton Farygin]

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


Скорее - для каждой категориии пользователей преимущество будет 
очевидным в том или ином случае.

Мне было бы удобнее rsyncable deflate (для зеркалирования Sisyphus). 
Тем, кто собирает или качает дистрибутивы - LZMA. Всем, кто не знает про 
rsync - LZMA

Осталось понять какая у нас группа пользователей самая большая и сделать 
изменение для её потребностей.

Подозреваю, что это будут те, кто предпочли бы (если б знали, что это) - 
LZMA.

Дим, можешь сказать, по каким протоколам у нас больше тянут с сервера - 
rsync или группа ftp + http?

Re: [devel] comprehensive rsyncability test

[Anton Farygin]

Mikhail Gusarov пишет:
> Twas brillig at 16:18:58 01.06.2008 UTC+04 when Anton Farygin did gyre and gimble:
> 
>  AF> Дим, можешь сказать, по каким протоколам у нас больше тянут с сервера -
>  AF> rsync или группа ftp + http?
> 
> Это будет некорректное сравнение - по умолчанию в дистрибутивах-то ftp, а
> умолчание можно всегда сменить.

Подозреваю, что в случае с apt'ом нам rsync не поможет.

Более того - нагрузка на сервер будет выше, чем сейчас с ftp.

Re: [devel] comprehensive rsyncability test

[Anton Farygin]

Alexander Bokovoy пишет:
> 1 июня 2008 г. 16:26 пользователь Anton Farygin <rider@altlinux.com> написал:
>>>  AF> Дим, можешь сказать, по каким протоколам у нас больше тянут с сервера
>>>  AF> rsync или группа ftp + http?
>>>
>>> Это будет некорректное сравнение - по умолчанию в дистрибутивах-то ftp, а
>>> умолчание можно всегда сменить.
>> Подозреваю, что в случае с apt'ом нам rsync не поможет.
>>
>> Более того - нагрузка на сервер будет выше, чем сейчас с ftp.
> Нет, нагрузка будет ниже. Антон, ты был невнимателен. :-)
> 
> Поддержка rsyncable gzip  в rpm и репозитарии позволяет нам сделать
> сразу два действия:
> 1. Оптимизировать работу по rsync: меньше объем данных для
> последовательных синхронизаций, меньше нагрузка на сервер _и_ клиент,
> поскольку анализ блоков rsync все равно производит, а данные в удобном
> для rsync формате позволяют этот анализ сократить.
> 2. Перевести клиентов по умолчанию с ftp на http с поддержкой zsync,
> использующий свойства того же rsyncable gzip.
> 
> При грамотной подготовке (а Алексей проделал уже две трети работы) мы
> разгрузим сервер.

Да, этот момент я пропустил. Если так, то конечно - я обеими руками за 
rsync.

Re: [devel] comprehensive rsyncability test

[Mikhail Gusarov]

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

Twas brillig at 16:18:58 01.06.2008 UTC+04 when Anton Farygin did gyre and gimble:

 AF> Дим, можешь сказать, по каким протоколам у нас больше тянут с сервера -
 AF> rsync или группа ftp + http?

Это будет некорректное сравнение - по умолчанию в дистрибутивах-то ftp, а
умолчание можно всегда сменить.

-- 
JID: dottedmag@altlinux.org / dottedmag@jabber.dottedmag.net

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

Re: [devel] comprehensive rsyncability test

[Alexander Bokovoy]

1 июня 2008 г. 16:26 пользователь Anton Farygin <rider@altlinux.com> написал:
>>  AF> Дим, можешь сказать, по каким протоколам у нас больше тянут с сервера
>>  AF> rsync или группа ftp + http?
>>
>> Это будет некорректное сравнение - по умолчанию в дистрибутивах-то ftp, а
>> умолчание можно всегда сменить.
>
> Подозреваю, что в случае с apt'ом нам rsync не поможет.
>
> Более того - нагрузка на сервер будет выше, чем сейчас с ftp.
Нет, нагрузка будет ниже. Антон, ты был невнимателен. :-)

Поддержка rsyncable gzip  в rpm и репозитарии позволяет нам сделать
сразу два действия:
1. Оптимизировать работу по rsync: меньше объем данных для
последовательных синхронизаций, меньше нагрузка на сервер _и_ клиент,
поскольку анализ блоков rsync все равно производит, а данные в удобном
для rsync формате позволяют этот анализ сократить.
2. Перевести клиентов по умолчанию с ftp на http с поддержкой zsync,
использующий свойства того же rsyncable gzip.

При грамотной подготовке (а Алексей проделал уже две трети работы) мы
разгрузим сервер.
-- 
/ Alexander Bokovoy

Re: [devel] comprehensive rsyncability test

[Alexander Bokovoy]

1 июня 2008 г. 16:26 пользователь Anton Farygin <rider@altlinux.com> написал:
>>  AF> Дим, можешь сказать, по каким протоколам у нас больше тянут с сервера
>>  AF> rsync или группа ftp + http?
>>
>> Это будет некорректное сравнение - по умолчанию в дистрибутивах-то ftp, а
>> умолчание можно всегда сменить.
>
> Подозреваю, что в случае с apt'ом нам rsync не поможет.
>
> Более того - нагрузка на сервер будет выше, чем сейчас с ftp.
Нет, нагрузка будет ниже. Антон, ты был невнимателен. :-)

Поддержка rsyncable gzip  в rpm и репозитарии позволяет нам сделать
сразу два действия:
1. Оптимизировать работу по rsync: меньше объем данных для
последовательных синхронизаций, меньше нагрузка на сервер _и_ клиент,
поскольку анализ блоков rsync все равно производит, а данные в удобном
для rsync формате позволяют этот анализ сократить.
2. Перевести клиентов по умолчанию с ftp на http с поддержкой zsync,
использующий свойства того же rsyncable gzip.

При грамотной подготовке (а Алексей проделал уже две трети работы) мы
разгрузим сервер.

-- 
/ Alexander Bokovoy

Re: [devel] comprehensive rsyncability test

[Alexey Tourbin]

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

On Sun, Jun 01, 2008 at 05:49:30PM +0400, Alexander Bokovoy wrote:
> 2. Перевести клиентов по умолчанию с ftp на http с поддержкой zsync,
> использующий свойства того же rsyncable gzip.

Насколько я понял, чтобы заработал zsync, для каждого *.rpm файла нужно
создать соответствующий ему *.rpm.zsync файл.  Феерично, в принципе говоря.

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

Re: [devel] comprehensive rsyncability test

[Alexander Bokovoy]

1 июня 2008 г. 19:35 пользователь Alexey Tourbin <at@altlinux.ru> написал:
> On Sun, Jun 01, 2008 at 05:49:30PM +0400, Alexander Bokovoy wrote:
>> 2. Перевести клиентов по умолчанию с ftp на http с поддержкой zsync,
>> использующий свойства того же rsyncable gzip.
>
> Насколько я понял, чтобы заработал zsync, для каждого *.rpm файла нужно
> создать соответствующий ему *.rpm.zsync файл.  Феерично, в принципе говоря.
Можно предложить другой вариант. Там же файлики маленькие, можно
сделать какой-нибудь cpio из файлов в одной директории, будет вполне
себе небольшим, а количество таких файлов будет ограничено количеством
директорий.


-- 
/ Alexander Bokovoy

Re: [devel] comprehensive rsyncability test

[Mikhail Gusarov]

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

Twas brillig at 20:38:29 01.06.2008 UTC+04 when Alexander Bokovoy did gyre and gimble:

 AB> Можно предложить другой вариант. Там же файлики маленькие, можно сделать
 AB> какой-нибудь cpio из файлов в одной директории, будет вполне себе
 AB> небольшим, а количество таких файлов будет ограничено количеством
 AB> директорий.

А насколько небольшой? Если шинковать по директориям, то apt'у будет неудобно -
для стягивания одного пакета придётся сначала добыть zsync-файл для всех пакетов
данной архитектуры.

-- 
JID: dottedmag@altlinux.org / dottedmag@jabber.dottedmag.net

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

Re: [devel] comprehensive rsyncability test

[Alexander Bokovoy]

1 июня 2008 г. 20:42 пользователь Mikhail Gusarov
<dottedmag@altlinux.org> написал:
> Twas brillig at 20:38:29 01.06.2008 UTC+04 when Alexander Bokovoy did gyre and gimble:
>
>  AB> Можно предложить другой вариант. Там же файлики маленькие, можно сделать
>  AB> какой-нибудь cpio из файлов в одной директории, будет вполне себе
>  AB> небольшим, а количество таких файлов будет ограничено количеством
>  AB> директорий.
>
> А насколько небольшой? Если шинковать по директориям, то apt'у будет неудобно -
> для стягивания одного пакета придётся сначала добыть zsync-файл для всех пакетов
> данной архитектуры.
При средней длине списка блоков в 700 байт для 55000 файлов в
репозитарии это будет порядка 35Мб данных. Это для всего текущего
репозитария, для всех архитектур.

Можно в принципе такой контрольный файл генерировать прямо при записи
rpm, поскольку эта информация доступна ровно в этот момент времени.  А
можно его положить вообще в rpm header по стабильному смещению так,
чтобы он внутри RPM хранился. И тогда любой запрос с "Range: этот
блок" будет отдавать доступную информацию.
-- 
/ Alexander Bokovoy

Re: [devel] comprehensive rsyncability test

[Mikhail Gusarov]

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

Twas brillig at 20:55:28 01.06.2008 UTC+04 when Alexander Bokovoy did gyre and gimble:

 AB> При средней длине списка блоков в 700 байт для 55000 файлов в репозитарии
 AB> это будет порядка 35Мб данных. Это для всего текущего репозитария, для всех
 AB> архитектур.

Т.е. будет три файла по 10-12 мегабайт: для noarch, i586 и x86_64. Это, конечно,
лучше, чем 55000 новых мелких файлов в репозитории, но всё равно как-то не то :)

 AB> И тогда любой запрос с "Range: этот блок" будет отдавать доступную
 AB> информацию.

Вот, такой вариант гораздо интереснее.

-- 
JID: dottedmag@altlinux.org / dottedmag@jabber.dottedmag.net

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

Re: [devel] comprehensive rsyncability test

[Michael Shigorin]

On Sun, Jun 01, 2008 at 12:11:50PM +0400, Alexey Tourbin wrote:
> Если те же самые файлы сжать с помощью 'lzma -2' или 'lzma -5',
> то получим 1.87G и 1.73G соответственно.  Напомню, что при
> синхронизации rsync скачал 1.57G.  Несколько точнее, разница
> между 1.57G и 1.73G в данном случае 172M.

С учётом того, что есть ещё нечасто обновляемые бегемоты 
(и прочее; а также и что для использования старых файлов надо
знать rsync(1) чуть лучше, скажем, моего) -- возможно, имеет
смысл подумать как раз в сторону lzma.  Такие пакеты будут
работать только с соответствующим rpm?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] comprehensive rsyncability test

[Michael Shigorin]

On Sun, Jun 01, 2008 at 02:18:58PM +0400, Alexey Tourbin wrote:
> 3) Конечно, есть ещё один аспект проблемы.  LZMA даёт прямое
> преимущество, потому что уменьшение размера файла напрямую влияет
> на объем для скачивания; а rsyncability даёт только косвенное/
> гипотетическое преимущество.  Чтобы преимущество rsync могло
> реализоваться, должны быть выполнены три условия: у пользователя есть
> старые файлы; старые файлы пожаты в rsyncable deflate; и пользователь
> правильно организовал процесс синхронизации.
> 
> Этот аспект проблемы трудно оценить численно, но он является
> достаточно важным.
> 
> Таким образом, я считаю, что в вопросе "rsyncable deflate vs LZMA"
> ни один из вариантов не имеет решающих преимуществ.

IMHO пользователи, у которых выполняются два зависящих от них
условия -- как правило, достаточно давно в ИТ, чтобы иметь или 
нетолстую, но безлимитку, или толстый канал неподалёку; а также
имеют скорее полные зеркала.  Поэтому может иметь смысл оценка
с учётом возможности пережать, скажем, весь сизиф ближе к бранчу
4.2 (или пока 4.1 не сильно расползся, чтоб хардлинкуемость не
терять).

Бишь плюс-минус пять прОцентов на обновлениях пакетов большой
погоды для них (нас), похоже, не сделают -- а вот уменьшение
общего объёма пакетной базы на ту же величину более
чувствительно.

Мне так кажется (c)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] comprehensive rsyncability test

[Mikhail Gusarov]

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

Twas brillig at 20:35:07 01.06.2008 UTC+03 when Michael Shigorin did gyre and gimble:

 MS> а также и что для использования старых файлов надо знать rsync(1) чуть
 MS> лучше, скажем, моего)

А зачем пользователю это знать? Это дело apt (для юзеров) и sisyphus-mirror (для
сисадминов).

-- 
JID: dottedmag@altlinux.org / dottedmag@jabber.dottedmag.net

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

Re: [devel] comprehensive rsyncability test

[Alexander Bokovoy]

1 июня 2008 г. 21:35 пользователь Michael Shigorin <mike@osdn.org.ua> написал:
> On Sun, Jun 01, 2008 at 12:11:50PM +0400, Alexey Tourbin wrote:
>> Если те же самые файлы сжать с помощью 'lzma -2' или 'lzma -5',
>> то получим 1.87G и 1.73G соответственно.  Напомню, что при
>> синхронизации rsync скачал 1.57G.  Несколько точнее, разница
>> между 1.57G и 1.73G в данном случае 172M.
>
> С учётом того, что есть ещё нечасто обновляемые бегемоты
> (и прочее; а также и что для использования старых файлов надо
> знать rsync(1) чуть лучше, скажем, моего) -- возможно, имеет
> смысл подумать как раз в сторону lzma.  Такие пакеты будут
> работать только с соответствующим rpm?
Для того, чтобы использовать rsync с rsyncable gzip в репозитарии,
достаточно использовать опцию -y (--fuzzy), которая позволяет неточно
сопоставлять имена файлов (по алгоритму Левенштейна). И
--delete-after, чтобы "ненужные" файлы сразу не удалились.

Поддержка LZMA в rpm есть в git Алексея, наравне с поддержкой
rsyncable gzip. Я по-прежнему считаю, что аргументов на включение lzma
по-умолчанию у нас на самом деле нет. "Перед смертью не надышишься", в
том смысле, что сокращение размеров отдельных rpm не решит проблему с
CD и другими ограниченными средствами хранения, а только лишь отсрочит
наступление этой проблемы -- и совсем не до состояния их вымирания.
-- 
/ Alexander Bokovoy

Re: [devel] comprehensive rsyncability test

[Mikhail Gusarov]

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

Twas brillig at 20:41:57 01.06.2008 UTC+03 when Michael Shigorin did gyre and gimble:

 MS> Бишь плюс-минус пять прОцентов на обновлениях пакетов большой погоды для
 MS> них (нас), похоже, не сделают

Школьный проект.

Пять дней сосать обновления по 64kbit-каналу вместо шести - это чувствительно, а
последовательно вставить шесть присланных по почте дисков вместо пяти - гораздо
менее.

-- 
JID: dottedmag@altlinux.org / dottedmag@jabber.dottedmag.net

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

Re: [devel] comprehensive rsyncability test

[Michael Shigorin]

On Mon, Jun 02, 2008 at 12:43:18AM +0700, Mikhail Gusarov wrote:
> > а также и что для использования старых файлов надо знать
> > rsync(1) чуть лучше, скажем, моего)
> А зачем пользователю это знать? Это дело apt (для юзеров)
> и sisyphus-mirror (для сисадминов).

Мож и так... тут более важное упустил с разбегу -- апдейты.

---
<mike> эт для апдейтов было бы хорошо
<mike> но там _в принципе_ есть другой вариант (btw вроде ползёт
       в федору из opensuse) -- patch rpms
<mike> (или delta rpms)
<mike> потому как у апдейтов как раз такая ситуация -- шансы на
       невеликость изменений большого пакета существенные
<dottedmag> А он по результату ничем не будет отличаться от того, что сейчас at делает.
<mike> *несущественность %)
<dottedmag> Просто другой эквивалентный механизм.
<mike> ну, всунуть побольше на блин тоже охота
<mike> но апдейты, наверное, важнее
<dottedmag> Будет lzma - deltarpm будут гораздо больше по размеру :)
<mike> как-то это проморгал сходу
<dottedmag> Собственно, это то, о чём писал at: всегда будет
            traceoff между размером дельты и степенью сжатия.
<mike> идеально бы такой трейдофф решать попакетно, конечно...
       для опенофисов с ядрами, мозиллами и иксами -- под rsync,
       для шрифтов и техов -- под lzma
<mike> ага
<mike> ну в смысле иметь к нему ручку. :)
---

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[devel] [JT] насчёт НП-18

[Michael Shigorin]

On Mon, Jun 02, 2008 at 12:47:51AM +0700, Mikhail Gusarov wrote:
> > Бишь плюс-минус пять прОцентов на обновлениях пакетов большой
> > погоды для них (нас), похоже, не сделают
> Школьный проект.

На самом деле не хотелось бы, чтоб он поглотил ALT Linux 
как эдакий мега-OEM.

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

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] [JT] насчёт НП-18

[Mikhail Gusarov]

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

Twas brillig at 21:07:49 01.06.2008 UTC+03 when Michael Shigorin did gyre and gimble:

 MS> Поэтому те же доводы лучше излагать менее трагическим, более левитановским
 MS> тоном -- пользователи действительно водятся в местах, где трафик дико
 MS> дорогой или вообще редкость...

Да, ещё можно переформулировать как "российская специфика" :)

-- 
JID: dottedmag@altlinux.org / dottedmag@jabber.dottedmag.net

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

Re: [devel] comprehensive rsyncability test

[Alexey Tourbin]

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

On Sun, Jun 01, 2008 at 09:44:22PM +0400, Alexander Bokovoy wrote:
> Поддержка LZMA в rpm есть в git Алексея, наравне с поддержкой
> rsyncable gzip. Я по-прежнему считаю, что аргументов на включение lzma
> по-умолчанию у нас на самом деле нет. "Перед смертью не надышишься", в
> том смысле, что сокращение размеров отдельных rpm не решит проблему с
> CD и другими ограниченными средствами хранения, а только лишь отсрочит
> наступление этой проблемы -- и совсем не до состояния их вымирания.

Всё относительно.  rsync дал меньше, чем я сначала ожидал.

Продолжу наглядную аналогию.

Допустим, у нас есть гипотетический средний rpm пакет, пожатый гзипом,
размером в 1 условную единицу объема.  Раздели этот пакет на четыре
части и выкни одну из них -- получится 0.75 единиц объема; это средний
эффект от перепаковки в LZMA.

Допустим, мы скачиваем этот пакет, перепакованный в LZMA, один раз,
и потом скачиваем новую версию этого пакета второй раз.  Тогда в сумме
мы скачиваем 0.75*2 = 1.5 единиц объема.

Теперь допустим, что мы препаковали этот пакет в rsyncable deflate;
размер остался прежним -- 1, зато при следущей синхронизации новой
версии этого пакета нам нужно скачать всего 2/3.  В сумме за два
скачивания получается 1.67 единиц объема.

При ТРЕТЬЕМ скачивании пакета объем составит 2.25 и 2.33, всё ещё
в пользу LZMA, а при ЧЕТВЕРТОМ скачивании эффект от LZMA и rsyncable
deflate, наконец, сравняется: 4*0.75 = 1+3*2/3 = 3.  И только при ПЯТОМ
скачивании потенциальное преимущество rsync будет, наконец, реализовано.

Не является ли потенциальное преимущество rsync слишком призрачным?

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

Re: [devel] comprehensive rsyncability test

[Led]

Sunday, 01 June 2008 21:22:33 Alexey Tourbin написав:
> On Sun, Jun 01, 2008 at 09:44:22PM +0400, Alexander Bokovoy wrote:
> > Поддержка LZMA в rpm есть в git Алексея, наравне с поддержкой
> > rsyncable gzip. Я по-прежнему считаю, что аргументов на включение lzma
> > по-умолчанию у нас на самом деле нет. "Перед смертью не надышишься", в
> > том смысле, что сокращение размеров отдельных rpm не решит проблему с
> > CD и другими ограниченными средствами хранения, а только лишь отсрочит
> > наступление этой проблемы -- и совсем не до состояния их вымирания.
>
> Всё относительно.  rsync дал меньше, чем я сначала ожидал.
>
> Продолжу наглядную аналогию.
>
> Допустим, у нас есть гипотетический средний rpm пакет, пожатый гзипом,
> размером в 1 условную единицу объема.  Раздели этот пакет на четыре
> части и выкни одну из них -- получится 0.75 единиц объема; это средний
> эффект от перепаковки в LZMA.
>
> Допустим, мы скачиваем этот пакет, перепакованный в LZMA, один раз,
> и потом скачиваем новую версию этого пакета второй раз.  Тогда в сумме
> мы скачиваем 0.75*2 = 1.5 единиц объема.
>
> Теперь допустим, что мы препаковали этот пакет в rsyncable deflate;
> размер остался прежним -- 1, зато при следущей синхронизации новой
> версии этого пакета нам нужно скачать всего 2/3.  В сумме за два
> скачивания получается 1.67 единиц объема.
>
> При ТРЕТЬЕМ скачивании пакета объем составит 2.25 и 2.33, всё ещё
> в пользу LZMA, а при ЧЕТВЕРТОМ скачивании эффект от LZMA и rsyncable
> deflate, наконец, сравняется: 4*0.75 = 1+3*2/3 = 3.  И только при ПЯТОМ
> скачивании потенциальное преимущество rsync будет, наконец, реализовано.
>
> Не является ли потенциальное преимущество rsync слишком призрачным?

ИМХО для тех, кто rsync'ает репозитарий ежедневно (или, хотя бы, 2-3 раза в 
неделю) - нет (не "слишком призрачным"). А вот для тех, кто "вот обновился из 
сизифа - давно уже обновлялся"... без статистки по таким "активным" 
пользователям - никак не определишь, что лучше...

-- 
Led

Re: [devel] comprehensive rsyncability test

[Alexey I. Froloff]

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

* Mikhail Gusarov <dottedmag@> [080601 21:45]:
>  MS> а также и что для использования старых файлов надо знать rsync(1) чуть
>  MS> лучше, скажем, моего)
> А зачем пользователю это знать? Это дело apt (для юзеров)
Хм.  А на чём будет выигрыш rsyncability даже при использовании
rsync:// в apt?  Я вижу один случай из нескольких возможных, да и
то с оговорками.

-- 
Regards,
Sir Raorn.

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

Re: [devel] comprehensive rsyncability test

[Alexey Tourbin]

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

On Sun, Jun 01, 2008 at 09:32:50PM +0300, Led wrote:
> > При ТРЕТЬЕМ скачивании пакета объем составит 2.25 и 2.33, всё ещё
> > в пользу LZMA, а при ЧЕТВЕРТОМ скачивании эффект от LZMA и rsyncable
> > deflate, наконец, сравняется: 4*0.75 = 1+3*2/3 = 3.  И только при ПЯТОМ
> > скачивании потенциальное преимущество rsync будет, наконец, реализовано.
> >
> > Не является ли потенциальное преимущество rsync слишком призрачным?
> 
> ИМХО для тех, кто rsync'ает репозитарий ежедневно (или, хотя бы, 2-3 раза в 
> неделю) - нет (не "слишком призрачным"). А вот для тех, кто "вот обновился из 
> сизифа - давно уже обновлялся"... без статистки по таким "активным" 
> пользователям - никак не определишь, что лучше...

Это на самом деле зависит от того, как часто (в среднем) собирают один и
тот же пакет.  Два раза в год?  В каталоге files/SRPMS/ у нас лежит 1013
src.rpm пакетов от 2005 года и более ранних (всего 7914 файлов).  И
примерно столько же пакетов от 2005 года и более ранних лежит в orphaned.

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

[devel] rsync server load

[Alexey Tourbin]

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

On Sun, Jun 01, 2008 at 05:48:46PM +0400, Alexander Bokovoy wrote:
> 1. Оптимизировать работу по rsync: меньше объем данных для
> последовательных синхронизаций, меньше нагрузка на сервер _и_ клиент,
> поскольку анализ блоков rsync все равно производит, а данные в удобном
> для rsync формате позволяют этот анализ сократить.

Нагрузка на сервер от rsync'а -- это какая-то городская легенда.

rsync(1):

	Rsync finds files that need to be transferred using a "quick check"
	algorithm (by default) that looks for files that have changed in size
	or in last-modified time.

Когда кто-то синхронизирует сизиф, rsync server сканирует не все поряд
файлы, а только те, которые изменились (то есть новые rpm пакеты).
Файлов же менятся ограниченное количество (для x86_64 -- 2.3G в месяц).
Значит, если воткнуть в сервер лишние 2G, которые стоят $100 или вроде
того (а также нужно смонтировать фс с опцией noatime), то rsync server
перейдёт преимущественно в in-memory режим.

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

Re: [devel] rsync server load

[Konstantin A. Lepikhov]

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

Hi Alexey!

Monday 02, at 01:17:42 AM you wrote:

> On Sun, Jun 01, 2008 at 05:48:46PM +0400, Alexander Bokovoy wrote:
> > 1. Оптимизировать работу по rsync: меньше объем данных для
> > последовательных синхронизаций, меньше нагрузка на сервер _и_ клиент,
> > поскольку анализ блоков rsync все равно производит, а данные в удобном
> > для rsync формате позволяют этот анализ сократить.
> 
> Нагрузка на сервер от rsync'а -- это какая-то городская легенда.
> 
> rsync(1):
> 
> 	Rsync finds files that need to be transferred using a "quick check"
> 	algorithm (by default) that looks for files that have changed in size
> 	or in last-modified time.
> 
> Когда кто-то синхронизирует сизиф, rsync server сканирует не все поряд
> файлы, а только те, которые изменились (то есть новые rpm пакеты).
> Файлов же менятся ограниченное количество (для x86_64 -- 2.3G в месяц).
> Значит, если воткнуть в сервер лишние 2G, которые стоят $100 или вроде
> того (а также нужно смонтировать фс с опцией noatime), то rsync server
> перейдёт преимущественно в in-memory режим.
+ если добавить commit=1000 для ext3. Будет вообще шоколадно.

-- 
WBR et al.

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

Re: [devel] [JT] насчёт НП-18

[Anton Farygin]

Mikhail Gusarov пишет:
> Twas brillig at 21:07:49 01.06.2008 UTC+03 when Michael Shigorin did gyre and gimble:
> 
>  MS> Поэтому те же доводы лучше излагать менее трагическим, более левитановским
>  MS> тоном -- пользователи действительно водятся в местах, где трафик дико
>  MS> дорогой или вообще редкость...
> 
> Да, ещё можно переформулировать как "российская специфика" :)

И тут, в случае с apt'ом - rsync vs lzma - lzma безусловно полезнее.

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

Точнее - уверен, что никто не будет, за исключением небольшой группы 
продвинутых.

Re: [devel] [JT] насчёт НП-18

[Alexander Bokovoy]

2 июня 2008 г. 7:48 пользователь Anton Farygin <rider@altlinux.com> написал:
>
>
> Mikhail Gusarov пишет:
>>
>> Twas brillig at 21:07:49 01.06.2008 UTC+03 when Michael Shigorin did gyre
>> and gimble:
>>
>>  MS> Поэтому те же доводы лучше излагать менее трагическим, более
>> левитановским
>>  MS> тоном -- пользователи действительно водятся в местах, где трафик дико
>>  MS> дорогой или вообще редкость...
>>
>> Да, ещё можно переформулировать как "российская специфика" :)
>
> И тут, в случае с apt'ом - rsync vs lzma - lzma безусловно полезнее.
>
> Не думаю, что все пользователи будут хранить предыдущие пакеты для
> возможности прогнать по ним rsync.
>
> Точнее - уверен, что никто не будет, за исключением небольшой группы
> продвинутых.
Учитель, получивший диски для установки, никуда их не выбросит. Имея
8-10 машин в классе, обновлять их по-одной будет не так удобно, как
обеспечить хранение обновлений на одной машине и превращение ее
временно в сервер обновлений.

Я уже указывал на #altlinux на несложность организации avahi-based
системы обновления для apt. О том, что это делается довольно легко,
показывает пример gitjour -- публикация git-репозитариев в локальной
сети. (http://micke.hallendal.net/blog/more-rubygit-greatness/).

Вообще, в этой области довольно легко добиться хорошего прогресса с
точки зрения упрощения использования. Нужно только немного посмотреть
вокруг и перестать думать о примитивных проблемах "нехватки" места на
дисках. Его _всегда_ будет не хватать, это реальность, что бы мы не
делали. Нужно заниматься более важными проблемами: упрощение типичных
задач администрирования (и это значит не только написание новых
модулей alterator!, но и упрощение реальных конфигураций с разбиением
их на типовые блоки), повышение повторной используемости доступных
ресурсов, передача лучших практик и так далее. Система должна стать
лучше за счет внутренних резервов, а не административного фактора.

Понятно, что для этого нужно четкое планирование и понимание общих
целей. Я далек от мысли, что школьный проект, например, является общей
целью всей ALT Linux Team, но некоторые из шагов мы -- как команда в
целом -- можем предпринять вместе. На сегодня же у нас сложилась
ситуация, когда никакой общей цели или целей у команды нет, равно как
и понимания того, зачем нужно действовать вместе. Я не буду пока
углубляться в эту тему, хотя определенные мысли по улучшению ситуации
в долговременном плане у меня есть.

Возвращаясь к rsyncable rpm/zsync-подобному управлению репозитариями,
эта деятельность направлена на упрощение воспроизводимости
инфраструктуры поддержки в относительно изолированных условиях. Нужна
ли она ООО? Предлагаю подумать самому ООО. Проекту же, как мне
видится, в долгосрочной перспективе это нужнее, чем очередные попытки
вместить на один диск конечное число rpm.
-- 
/ Alexander Bokovoy

Re: [devel] [JT] насчёт НП-18

[Sergey Bolshakov]

>>>>> "Alexander" == Alexander Bokovoy <ab-u2l5PoMzF/Vg9hUCZPvPmw@public.gmane.org> writes:
[skipped]

 > Я уже указывал на #altlinux на несложность организации avahi-based
 > системы обновления для apt. О том, что это делается довольно легко,
 > показывает пример gitjour -- публикация git-репозитариев в локальной
 > сети. (http://micke.hallendal.net/blog/more-rubygit-greatness/).
Организация публикации локального репозитария сводится к
помещению файла специального вида в /etc/avahi.
Есть ли желающие приделать к апту умение находить
посредством mdns урл такого репозитария ?

 > Вообще, в этой области довольно легко добиться хорошего прогресса с
 > точки зрения упрощения использования. Нужно только немного посмотреть
 > вокруг и перестать думать о примитивных проблемах "нехватки" места на
 > дисках. Его _всегда_ будет не хватать, это реальность, что бы мы не
 > делали. Нужно заниматься более важными проблемами: упрощение типичных
 > задач администрирования (и это значит не только написание новых
 > модулей alterator!, но и упрощение реальных конфигураций с разбиением
 > их на типовые блоки), повышение повторной используемости доступных
 > ресурсов, передача лучших практик и так далее. Система должна стать
 > лучше за счет внутренних резервов, а не административного фактора.
Считай, сорвал апплодисменты.
Осталось найти желающих заняться нудными деталями реализации.

-- 

Re: [devel] [JT] насчёт НП-18

[Anton Farygin]

Alexander Bokovoy пишет:
> 2 июня 2008 г. 7:48 пользователь Anton Farygin <rider@altlinux.com> написал:
>>
>> Mikhail Gusarov пишет:
>>> Twas brillig at 21:07:49 01.06.2008 UTC+03 when Michael Shigorin did gyre
>>> and gimble:
>>>
>>>  MS> Поэтому те же доводы лучше излагать менее трагическим, более
>>> левитановским
>>>  MS> тоном -- пользователи действительно водятся в местах, где трафик дико
>>>  MS> дорогой или вообще редкость...
>>>
>>> Да, ещё можно переформулировать как "российская специфика" :)
>> И тут, в случае с apt'ом - rsync vs lzma - lzma безусловно полезнее.
>>
>> Не думаю, что все пользователи будут хранить предыдущие пакеты для
>> возможности прогнать по ним rsync.
>>
>> Точнее - уверен, что никто не будет, за исключением небольшой группы
>> продвинутых.
> Учитель, получивший диски для установки, никуда их не выбросит. Имея
> 8-10 машин в классе, обновлять их по-одной будет не так удобно, как
> обеспечить хранение обновлений на одной машине и превращение ее
> временно в сервер обновлений.

Согласен. Но (если говорить о школьном проекте этого года) - тут мы уже 
упустили время, и всё, о чём мы можем можем говорить - о дистрибутивах 
на базе post-4.2 бранча.

rsync безусловно даст преимущества всем, кто зеркалит и всем, кто осилит 
копирование с CD/DVD на диск.

Но в данном случае - не имеет значения, будет ли это алгоритм для rsync 
или lzma.


> 
> Я уже указывал на #altlinux на несложность организации avahi-based
> системы обновления для apt. О том, что это делается довольно легко,
> показывает пример gitjour -- публикация git-репозитариев в локальной
> сети. (http://micke.hallendal.net/blog/more-rubygit-greatness/)

Re: [devel] [JT] насчёт НП-18

[Aleksey Novodvorsky]

02.06.08, Anton Farygin<rider@altlinux.com> написал(а):
>
>
>  Alexander Bokovoy пишет:
>
> > 2 июня 2008 г. 7:48 пользователь Anton Farygin <rider@altlinux.com>
> написал:
> >
> > >
> > > Mikhail Gusarov пишет:
> > >
> > > > Twas brillig at 21:07:49 01.06.2008 UTC+03 when Michael Shigorin did
> gyre
> > > > and gimble:
> > > >
> > > >  MS> Поэтому те же доводы лучше излагать менее трагическим, более
> > > > левитановским
> > > >  MS> тоном -- пользователи действительно водятся в местах, где трафик
> дико
> > > >  MS> дорогой или вообще редкость...
> > > >
> > > > Да, ещё можно переформулировать как "российская специфика" :)
> > > >
> > > И тут, в случае с apt'ом - rsync vs lzma - lzma безусловно полезнее.
> > >
> > > Не думаю, что все пользователи будут хранить предыдущие пакеты для
> > > возможности прогнать по ним rsync.
> > >
> > > Точнее - уверен, что никто не будет, за исключением небольшой группы
> > > продвинутых.
> > >
> > Учитель, получивший диски для установки, никуда их не выбросит. Имея
> > 8-10 машин в классе, обновлять их по-одной будет не так удобно, как
> > обеспечить хранение обновлений на одной машине и превращение ее
> > временно в сервер обновлений.

Надо включить сервер обновлений в Школьный сервер.

Rgrds, Алексей


> >
>
>  Согласен. Но (если говорить о школьном проекте этого года) - тут мы уже
> упустили время, и всё, о чём мы можем можем говорить - о дистрибутивах на
> базе post-4.2 бранча.
>
>  rsync безусловно даст преимущества всем, кто зеркалит и всем, кто осилит
> копирование с CD/DVD на диск.
>
>  Но в данном случае - не имеет значения, будет ли это алгоритм для rsync или
> lzma.
>
>
>
> >
> > Я уже указывал на #altlinux на несложность организации avahi-based
> > системы обновления для apt. О том, что это делается довольно легко,
> > показывает пример gitjour -- публикация git-репозитариев в локальной
> > сети.
> (http://micke.hallendal.net/blog/more-rubygit-greatness/)
> >
>  _______________________________________________
>  Devel mailing list
>  Devel@lists.altlinux.org
>  https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] comprehensive rsyncability test

[Alexey Tourbin]

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

On Sat, May 31, 2008 at 10:58:47PM +0400, Alexey Tourbin wrote:
> Предлагаю протестировать rsyncability двух каталогов:
> /ALT/archive/Sisyphus/2008/03/01/files/x86_64/RPMS
> /ALT/archive/Sisyphus/2008/04/01/files/x86_64/RPMS
> 
> Методика тестирования следующая:
> 1) Из каталогов парами выбираются файлы, у которых совпадает
> имя пакета %{NAME}, но при этом не совпадает имя файла
> %name-%version-%release.x86_64.rpm.
> 2) Для каждой пары пакетов извлекается cpio архив и перепаковывается
> с помощью rsyncable gzdio из нового rpmio.
> 3) Отсекаются маленькие пакеты: оба перепакованных архива должны быть
> больше 32K.
> 4) Запускается rsync, который диагностирует степень "совпадения" двух
> перепакованных архивов.
> 
> Полный результат приведён в таблице, которую я прицепил к письму.
> Таблица подразумевает следующий заголовок.
> 
> файл-1   размер-1   файл-2   размер-2   послано   скочено   speedup
> ------   --------   ------   --------   -------   -------   -------

> $ sum() { perl -MList::Util=sum -ln0 -e 'print sum split'; }
> $ cut -f4 rsyncability.txt |sum
> 2433627
> $
> 
> Общий размер новых пакетов 2.32G.
> 
> $ cut -f6 rsyncability.txt |sum
> 1643033
> $
> 
> При этом rsync скачал 1.57G.

Из интереса я запустил почти такой же тест, но для РАЗЖАТЫХ cpio.
Результаты получились следующие.

$ cut -f4 cpio.txt |sum
7091196
$

Общий объем новых пакетов в разжатов виде 6.76G.

$ cut -f6 cpio.txt |sum
3330604
$

При этом rsync скачал 3.18G, то есть 47% от расжатого объема.
Напомню, что для сжатых данных rsync скачал 67%.

О чём это говорт?  Это говорит о том, что rsync даже в идеале
не является радикальным решением проблемы синхронизации пакетов.
ДАННЫЕ В ПАКЕТАХ РЕАЛЬНО МЕНЯЮТСЯ (в репрезентативной выборке --
примерно наполовину по объему), так что rsync заведомо имеет некоторый
эмпирический предел.  Нельзя найти ещё больше совпадающих кусков там,
где их нет.

Это также говорит о том, что rsyncable deflate значительно уменьшает
максимально возможное значение rsyncability (отношение скаченного
rsync'ом к общему объему).  Это наводит на мысль, что rsyncable
compression по сути является компромиссом между compression и
rsyncability.  Ultimate compression получается при большой размере
словаря и исключает rsyncability.  А ultimate rsyncability получается
на несжатых данных.

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

Re: [devel] [JT] насчёт НП-18

[Mikhail Gusarov]

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

Twas brillig at 13:57:49 02.06.2008 UTC+04 when Aleksey Novodvorsky did gyre and gimble:

 AN> Надо включить сервер обновлений в Школьный сервер.

К этому обычно прилагается расчёт времени разработки и выделенные ресурсы :)

-- 
JID: dottedmag@altlinux.org / dottedmag@jabber.dottedmag.net

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

Re: [devel] comprehensive rsyncability test

[Alexander Bokovoy]

2 июня 2008 г. 14:06 пользователь Alexey Tourbin <at@altlinux.ru> написал:
>> При этом rsync скачал 1.57G.
>
> Из интереса я запустил почти такой же тест, но для РАЗЖАТЫХ cpio.
> Результаты получились следующие.
>
> $ cut -f4 cpio.txt |sum
> 7091196
> $
>
> Общий объем новых пакетов в разжатов виде 6.76G.
>
> $ cut -f6 cpio.txt |sum
> 3330604
> $
>
> При этом rsync скачал 3.18G, то есть 47% от расжатого объема.
> Напомню, что для сжатых данных rsync скачал 67%.
>
> О чём это говорт?  Это говорит о том, что rsync даже в идеале
> не является радикальным решением проблемы синхронизации пакетов.
> ДАННЫЕ В ПАКЕТАХ РЕАЛЬНО МЕНЯЮТСЯ (в репрезентативной выборке --
> примерно наполовину по объему), так что rsync заведомо имеет некоторый
> эмпирический предел.  Нельзя найти ещё больше совпадающих кусков там,
> где их нет.
>
> Это также говорит о том, что rsyncable deflate значительно уменьшает
> максимально возможное значение rsyncability (отношение скаченного
> rsync'ом к общему объему).  Это наводит на мысль, что rsyncable
> compression по сути является компромиссом между compression и
> rsyncability.  Ultimate compression получается при большой размере
> словаря и исключает rsyncability.  А ultimate rsyncability получается
> на несжатых данных.
Это экстремальные ситуации. Поиск оптимума можно продолжать, но
достигнутые 33% экономии в текущей ситуации вполне себя оправдывают.


-- 
/ Alexander Bokovoy

Re: [devel] [JT] насчёт НП-18

[Anton Farygin]

Aleksey Novodvorsky пишет:
> 02.06.08, Anton Farygin<rider@altlinux.com> написал(а):
>>
>>  Alexander Bokovoy пишет:
>>
>>> 2 июня 2008 г. 7:48 пользователь Anton Farygin <rider@altlinux.com>
>> написал:
>>>> Mikhail Gusarov пишет:
>>>>
>>>>> Twas brillig at 21:07:49 01.06.2008 UTC+03 when Michael Shigorin did
>> gyre
>>>>> and gimble:
>>>>>
>>>>>  MS> Поэтому те же доводы лучше излагать менее трагическим, более
>>>>> левитановским
>>>>>  MS> тоном -- пользователи действительно водятся в местах, где трафик
>> дико
>>>>>  MS> дорогой или вообще редкость...
>>>>>
>>>>> Да, ещё можно переформулировать как "российская специфика" :)
>>>>>
>>>> И тут, в случае с apt'ом - rsync vs lzma - lzma безусловно полезнее.
>>>>
>>>> Не думаю, что все пользователи будут хранить предыдущие пакеты для
>>>> возможности прогнать по ним rsync.
>>>>
>>>> Точнее - уверен, что никто не будет, за исключением небольшой группы
>>>> продвинутых.
>>>>
>>> Учитель, получивший диски для установки, никуда их не выбросит. Имея
>>> 8-10 машин в классе, обновлять их по-одной будет не так удобно, как
>>> обеспечить хранение обновлений на одной машине и превращение ее
>>> временно в сервер обновлений.
> 
> Надо включить сервер обновлений в Школьный сервер.
> 

сервер обновлений надо. Но не стоит это путать с lzma vs rsyncable rpm.

Пересобирать пакеты всего branch/4.x для смены алгоритма сжатия, врятли кто.

И вообще - не стоит в данном контекстей говорить о школьном проекте. 
Данная задача реально скажется на пользователях не раньше, чем через год.

Re: [devel] comprehensive rsyncability test

[Anton Farygin]

Alexander Bokovoy пишет:
> 2 июня 2008 г. 14:06 пользователь Alexey Tourbin <at@altlinux.ru> написал:
>>> При этом rsync скачал 1.57G.
>> Из интереса я запустил почти такой же тест, но для РАЗЖАТЫХ cpio.
>> Результаты получились следующие.
>>
>> $ cut -f4 cpio.txt |sum
>> 7091196
>> $
>>
>> Общий объем новых пакетов в разжатов виде 6.76G.
>>
>> $ cut -f6 cpio.txt |sum
>> 3330604
>> $
>>
>> При этом rsync скачал 3.18G, то есть 47% от расжатого объема.
>> Напомню, что для сжатых данных rsync скачал 67%.
>>
>> О чём это говорт?  Это говорит о том, что rsync даже в идеале
>> не является радикальным решением проблемы синхронизации пакетов.
>> ДАННЫЕ В ПАКЕТАХ РЕАЛЬНО МЕНЯЮТСЯ (в репрезентативной выборке --
>> примерно наполовину по объему), так что rsync заведомо имеет некоторый
>> эмпирический предел.  Нельзя найти ещё больше совпадающих кусков там,
>> где их нет.
>>
>> Это также говорит о том, что rsyncable deflate значительно уменьшает
>> максимально возможное значение rsyncability (отношение скаченного
>> rsync'ом к общему объему).  Это наводит на мысль, что rsyncable
>> compression по сути является компромиссом между compression и
>> rsyncability.  Ultimate compression получается при большой размере
>> словаря и исключает rsyncability.  А ultimate rsyncability получается
>> на несжатых данных.
> Это экстремальные ситуации. Поиск оптимума можно продолжать, но
> достигнутые 33% экономии в текущей ситуации вполне себя оправдывают.

Наверное, не стоит сбрасывать со счетов ещё необходимость пересборки 
всего существующего с новым алгоритмом сжатия.

Т.е. - по факту данное улучшение заработает для любого взятого пакета 
только на его третьем обновлении.

lzma будет заметно при первом же обновлении.

Re: [devel] rsync server load

[Dmitry V. Levin]

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

On Mon, Jun 02, 2008 at 01:17:42AM +0400, Alexey Tourbin wrote:
> On Sun, Jun 01, 2008 at 05:48:46PM +0400, Alexander Bokovoy wrote:
> > 1. Оптимизировать работу по rsync: меньше объем данных для
> > последовательных синхронизаций, меньше нагрузка на сервер _и_ клиент,
> > поскольку анализ блоков rsync все равно производит, а данные в удобном
> > для rsync формате позволяют этот анализ сократить.
> 
> Нагрузка на сервер от rsync'а -- это какая-то городская легенда.

Если сравнить процесс vsftpd, который в основном занимается тем, что делает
sendfile(2), с rsync -H, который при работе с 100G архивом не помещается
в 64M памяти и что-то считает, то vsftpd создаёт на порядки меньшую загрузку
чем rsync.  1024 одновременных ftp-сессий для vsftpd это не вопрос, а вот
128 rsync-сессий это уже проблема.

> rsync(1):
> 
> 	Rsync finds files that need to be transferred using a "quick check"
> 	algorithm (by default) that looks for files that have changed in size
> 	or in last-modified time.
> 
> Когда кто-то синхронизирует сизиф, rsync server сканирует не все поряд
> файлы, а только те, которые изменились (то есть новые rpm пакеты).
> Файлов же менятся ограниченное количество (для x86_64 -- 2.3G в месяц).
> Значит, если воткнуть в сервер лишние 2G, которые стоят $100 или вроде

2G серверной памяти для серверов предыдущего поколения (DDR1 ECC REG)
стоит примерно $240.  И хорошо ещё, если под неё есть свободный слот.

> того (а также нужно смонтировать фс с опцией noatime), то rsync server
> перейдёт преимущественно в in-memory режим.

Пока что такого in-memory добиться не удаётся.


-- 
ldv

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

Re: [devel] rsync server load

[Konstantin A. Lepikhov]

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

Hi Dmitry!

Monday 02, at 06:08:11 PM you wrote:

> On Mon, Jun 02, 2008 at 01:17:42AM +0400, Alexey Tourbin wrote:
> > On Sun, Jun 01, 2008 at 05:48:46PM +0400, Alexander Bokovoy wrote:
> > > 1. Оптимизировать работу по rsync: меньше объем данных для
> > > последовательных синхронизаций, меньше нагрузка на сервер _и_ клиент,
> > > поскольку анализ блоков rsync все равно производит, а данные в удобном
> > > для rsync формате позволяют этот анализ сократить.
> > 
> > Нагрузка на сервер от rsync'а -- это какая-то городская легенда.
> 
> Если сравнить процесс vsftpd, который в основном занимается тем, что делает
> sendfile(2), с rsync -H, который при работе с 100G архивом не помещается
> в 64M памяти и что-то считает, то vsftpd создаёт на порядки меньшую загрузку
> чем rsync.  1024 одновременных ftp-сессий для vsftpd это не вопрос, а вот
> 128 rsync-сессий это уже проблема.
> 
> > rsync(1):
> > 
> > 	Rsync finds files that need to be transferred using a "quick check"
> > 	algorithm (by default) that looks for files that have changed in size
> > 	or in last-modified time.
> > 
> > Когда кто-то синхронизирует сизиф, rsync server сканирует не все поряд
> > файлы, а только те, которые изменились (то есть новые rpm пакеты).
> > Файлов же менятся ограниченное количество (для x86_64 -- 2.3G в месяц).
> > Значит, если воткнуть в сервер лишние 2G, которые стоят $100 или вроде
> 
> 2G серверной памяти для серверов предыдущего поколения (DDR1 ECC REG)
> стоит примерно $240.  И хорошо ещё, если под неё есть свободный слот.
А OOO такое бедное, что не может купить новый сервер за $3000? Дим,
по-моему, это уже какой-то неприличный анекдот. Ну раз так все плохо,
давайте скинемся на сервер что-ли.

-- 
WBR et al.

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

Re: [devel] rsync server load

[Dmitry V. Levin]

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

On Mon, Jun 02, 2008 at 06:25:16PM +0400, Konstantin A. Lepikhov wrote:
[...]
> А OOO такое бедное, что не может купить новый сервер за $3000? Дим,

За $3000 получится некудышный сервер.


-- 
ldv

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

Re: [devel] rsync server load

[Konstantin A. Lepikhov]

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

Hi Dmitry!

Monday 02, at 06:29:38 PM you wrote:

> On Mon, Jun 02, 2008 at 06:25:16PM +0400, Konstantin A. Lepikhov wrote:
> [...]
> > А OOO такое бедное, что не может купить новый сервер за $3000? Дим,
> 
> За $3000 получится некудышный сервер.
Если их купить штук 5 и сделать load balancer, то получится нормальный
кластер, который еще и будет масштабируемым и отказоустойчивым. Нет,
вместо этого все мечтают о ftp на POWER и экономят на спичках.

-- 
WBR et al.

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

Re: [devel] [jt] rsync server load

[Dmitry V. Levin]

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

On Mon, Jun 02, 2008 at 10:04:12PM +0400, Konstantin A. Lepikhov wrote:
> Monday 02, at 06:29:38 PM you wrote:
> 
> > On Mon, Jun 02, 2008 at 06:25:16PM +0400, Konstantin A. Lepikhov wrote:
> > [...]
> > > А OOO такое бедное, что не может купить новый сервер за $3000? Дим,
> > 
> > За $3000 получится некудышный сервер.
> Если их купить штук 5 и сделать load balancer, то получится нормальный
> кластер, который еще и будет масштабируемым и отказоустойчивым.

Плюс ещё storage за сумму с 4 нулями.  Короче говоря, те, кто не знают,
где ты работаешь, могут подумать, что ты продвигаешь железо. :)


-- 
ldv

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

Re: [devel] comprehensive rsyncability test

[Dmitry V. Levin]

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

On Sun, Jun 01, 2008 at 02:18:58PM +0400, Alexey Tourbin wrote:
[...]
> Таким образом, я считаю, что в вопросе "rsyncable deflate vs LZMA"
> ни один из вариантов не имеет решающих преимуществ.

У меня сложилось то же самое мнение.  Есть две разные категории
пользователей репозитория, для которых выбор вариантов будет различным.
Давайте попробуем прикинуть, что предпочтительнее в кратко-, средне- и
долгосрочной перспективе.


-- 
ldv

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

Re: [devel] [jt] rsync server load

[Alexey Gladkov]

Dmitry V. Levin wrote:
> Плюс ещё storage за сумму с 4 нулями.  Короче говоря, те, кто не знают,
> где ты работаешь, могут подумать, что ты продвигаешь железо. :)

Жаль что те кто действительно продвигают железо молчат ... может по 
знакомству и/или из уважения к проекту сделают скидочку.

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

-- 
Rgrds, legion

Re: [devel] comprehensive rsyncability test

[Led]

Monday, 02 June 2008 23:24:51 Dmitry V. Levin написав:
> On Sun, Jun 01, 2008 at 02:18:58PM +0400, Alexey Tourbin wrote:
> [...]
>
> > Таким образом, я считаю, что в вопросе "rsyncable deflate vs LZMA"
> > ни один из вариантов не имеет решающих преимуществ.
>
> У меня сложилось то же самое мнение.  Есть две разные категории
> пользователей репозитория, для которых выбор вариантов будет различным.
> Давайте попробуем прикинуть, что предпочтительнее в кратко-, средне- и
> долгосрочной перспективе.

ИМХО:
для сизифа - rsyncable,
для дистрибутива и обновлений - максимальное сжаните в ущерб rsyncable.

-- 
Led

Re: [devel] [jt] rsync server load

[Dmitry V. Levin]

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

On Tue, Jun 03, 2008 at 12:28:51AM +0400, Alexey Gladkov wrote:
> Dmitry V. Levin wrote:
> >Плюс ещё storage за сумму с 4 нулями.  Короче говоря, те, кто не знают,
> >где ты работаешь, могут подумать, что ты продвигаешь железо. :)
> 
> Жаль что те кто действительно продвигают железо молчат ... может по 
> знакомству и/или из уважения к проекту сделают скидочку.

Обычно они этого не делают, а жаль.

> Нужно посчитать, может имеет смысл прислушаться к Косте и много, 
> недорогих серверов будут выгоднее.

Если Константин (или не Константин) составит более конкретный план, с
номерами моделей и ценами, тогда будет понятно, есть ли предмет для
обсуждения.


-- 
ldv

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

Re: [devel] [jt] rsync server load

[Alexey Gladkov]

Dmitry V. Levin wrote:
>>> Плюс ещё storage за сумму с 4 нулями.  Короче говоря, те, кто не знают,
>>> где ты работаешь, могут подумать, что ты продвигаешь железо. :)
>> Жаль что те кто действительно продвигают железо молчат ... может по 
>> знакомству и/или из уважения к проекту сделают скидочку.
> 
> Обычно они этого не делают, а жаль.

Не делают чего? Не высказываются, не уважают или скидки не делают ? :)

-- 
Rgrds, legion

Re: [devel] [jt] rsync server load

[Sergey Y. Afonin]

On Tuesday 03 June 2008, Dmitry V. Levin wrote:

> Плюс ещё storage за сумму с 4 нулями. 

Зачем ? А с тремя не хватит ? :-)

-- 
С уважением, Сергей Афонин

Re: [devel] [jt] rsync server load

[Sergey Y. Afonin]

On Tuesday 03 June 2008, Dmitry V. Levin wrote:

> Если Константин (или не Константин) составит более конкретный план, с
> номерами моделей и ценами,

Мы себе вот такую штуку купили:
http://www.infortrend.ru/main/2_product/es_a08(12)u-g2421.asp

-- 
С уважением, Сергей Афонин

Re: [devel] [jt] rsync server load

[Konstantin A. Lepikhov]

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

Hi Dmitry!

Tuesday 03, at 12:21:12 AM you wrote:

> On Mon, Jun 02, 2008 at 10:04:12PM +0400, Konstantin A. Lepikhov wrote:
> > Monday 02, at 06:29:38 PM you wrote:
> > 
> > > On Mon, Jun 02, 2008 at 06:25:16PM +0400, Konstantin A. Lepikhov wrote:
> > > [...]
> > > > А OOO такое бедное, что не может купить новый сервер за $3000? Дим,
> > > 
> > > За $3000 получится некудышный сервер.
> > Если их купить штук 5 и сделать load balancer, то получится нормальный
> > кластер, который еще и будет масштабируемым и отказоустойчивым.
> 
> Плюс ещё storage за сумму с 4 нулями.  Короче говоря, те, кто не знают,
> где ты работаешь, могут подумать, что ты продвигаешь железо. :)
нет, я начитался http://lbvm.sourceforge.net/ :) Кстати, у тебя устаревшие
взгляды - запчасти на storage за сумму с 4 нулями тебе будут тоже везти
время с 4 нулями, поэтому кластер из китайского мусора от supermicro и
SATA дисков всяко дешевле и меняется на раз. Нам же нужен не fault
tolerance с тысячной процента, латентность тоже несколько пофиг. Поэтому
сеть из кластеров в разных ДЦ рулит. Где купить это барахло для кластера -
помойму это даже etegro/rider@ может сказать, в MSK не так много крупных
поставщиков типа серверного железа от Dell/SuperMicro. Остается аренда
стойкоместа в ДЦ - ну это вопрос для отдельного разговора.

-- 
WBR et al.

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

Re: [devel] [jt] rsync server load

[Dmitry V. Levin]

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

On Tue, Jun 03, 2008 at 01:33:44AM +0400, Konstantin A. Lepikhov wrote:
> Tuesday 03, at 12:21:12 AM you wrote:
> > On Mon, Jun 02, 2008 at 10:04:12PM +0400, Konstantin A. Lepikhov wrote:
> > > Monday 02, at 06:29:38 PM you wrote:
> > > > On Mon, Jun 02, 2008 at 06:25:16PM +0400, Konstantin A. Lepikhov wrote:
> > > > [...]
> > > > > А OOO такое бедное, что не может купить новый сервер за $3000? Дим,
> > > > 
> > > > За $3000 получится некудышный сервер.
> > > Если их купить штук 5 и сделать load balancer, то получится нормальный
> > > кластер, который еще и будет масштабируемым и отказоустойчивым.
> > 
> > Плюс ещё storage за сумму с 4 нулями.  Короче говоря, те, кто не знают,
> > где ты работаешь, могут подумать, что ты продвигаешь железо. :)
> нет, я начитался http://lbvm.sourceforge.net/ :)

Да, читать бывает полезно. :)

> Кстати, у тебя устаревшие взгляды -
> запчасти на storage за сумму с 4 нулями тебе будут тоже везти
> время с 4 нулями, поэтому кластер из китайского мусора от supermicro и
> SATA дисков всяко дешевле и меняется на раз. Нам же нужен не fault
> tolerance с тысячной процента, латентность тоже несколько пофиг. Поэтому
> сеть из кластеров в разных ДЦ рулит. Где купить это барахло для кластера -
> помойму это даже etegro/rider@ может сказать, в MSK не так много крупных
> поставщиков типа серверного железа от Dell/SuperMicro. Остается аренда
> стойкоместа в ДЦ - ну это вопрос для отдельного разговора.

И всё же, сколько будет стоить shared storage для такой развесистой
клюквы?


-- 
ldv

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

Re: [devel] [jt] rsync server load

[Konstantin A. Lepikhov]

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

Hi Dmitry!

Tuesday 03, at 01:42:29 AM you wrote:

> On Tue, Jun 03, 2008 at 01:33:44AM +0400, Konstantin A. Lepikhov wrote:
> > Tuesday 03, at 12:21:12 AM you wrote:
> > > On Mon, Jun 02, 2008 at 10:04:12PM +0400, Konstantin A. Lepikhov wrote:
> > > > Monday 02, at 06:29:38 PM you wrote:
> > > > > On Mon, Jun 02, 2008 at 06:25:16PM +0400, Konstantin A. Lepikhov wrote:
> > > > > [...]
> > > > > > А OOO такое бедное, что не может купить новый сервер за $3000? Дим,
> > > > > 
> > > > > За $3000 получится некудышный сервер.
> > > > Если их купить штук 5 и сделать load balancer, то получится нормальный
> > > > кластер, который еще и будет масштабируемым и отказоустойчивым.
> > > 
> > > Плюс ещё storage за сумму с 4 нулями.  Короче говоря, те, кто не знают,
> > > где ты работаешь, могут подумать, что ты продвигаешь железо. :)
> > нет, я начитался http://lbvm.sourceforge.net/ :)
> 
> Да, читать бывает полезно. :)
> 
> > Кстати, у тебя устаревшие взгляды -
> > запчасти на storage за сумму с 4 нулями тебе будут тоже везти
> > время с 4 нулями, поэтому кластер из китайского мусора от supermicro и
> > SATA дисков всяко дешевле и меняется на раз. Нам же нужен не fault
> > tolerance с тысячной процента, латентность тоже несколько пофиг. Поэтому
> > сеть из кластеров в разных ДЦ рулит. Где купить это барахло для кластера -
> > помойму это даже etegro/rider@ может сказать, в MSK не так много крупных
> > поставщиков типа серверного железа от Dell/SuperMicro. Остается аренда
> > стойкоместа в ДЦ - ну это вопрос для отдельного разговора.
> 
> И всё же, сколько будет стоить shared storage для такой развесистой
> клюквы?
нету там shared storage. есть clustered fs.

-- 
WBR et al.

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

Re: [devel] [jt] clustered fs

[Dmitry V. Levin]

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

On Tue, Jun 03, 2008 at 02:25:12AM +0400, Konstantin A. Lepikhov wrote:
> Tuesday 03, at 01:42:29 AM you wrote:
[...]
> > И всё же, сколько будет стоить shared storage для такой развесистой
> > клюквы?
> нету там shared storage. есть clustered fs.

И что там за clustered fs, на какие задачи она рассчитана, какие у неё
характеристики по сравнению с локальной fs?


-- 
ldv

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

Re: [devel] [jt] clustered fs

[Konstantin A. Lepikhov]

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

Hi Dmitry!

Tuesday 03, at 02:50:10 AM you wrote:

> On Tue, Jun 03, 2008 at 02:25:12AM +0400, Konstantin A. Lepikhov wrote:
> > Tuesday 03, at 01:42:29 AM you wrote:
> [...]
> > > И всё же, сколько будет стоить shared storage для такой развесистой
> > > клюквы?
> > нету там shared storage. есть clustered fs.
> 
> И что там за clustered fs, на какие задачи она рассчитана, какие у неё
> характеристики по сравнению с локальной fs?
> 
http://en.wikipedia.org/wiki/Cluster_file_system ;)

-- 
WBR et al.

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

Re: [devel] [jt] clustered fs

[Dmitry V. Levin]

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

On Tue, Jun 03, 2008 at 02:54:12AM +0400, Konstantin A. Lepikhov wrote:
> Tuesday 03, at 02:50:10 AM you wrote:
> > On Tue, Jun 03, 2008 at 02:25:12AM +0400, Konstantin A. Lepikhov wrote:
> > > Tuesday 03, at 01:42:29 AM you wrote:
> > [...]
> > > > И всё же, сколько будет стоить shared storage для такой развесистой
> > > > клюквы?
> > > нету там shared storage. есть clustered fs.
> > 
> > И что там за clustered fs, на какие задачи она рассчитана, какие у неё
> > характеристики по сравнению с локальной fs?
> > 
> http://en.wikipedia.org/wiki/Cluster_file_system ;)

Понятно, абстрактная кластерная fs даёт абстрактную надёжность и не менее
абстрактную производительность. :)


-- 
ldv

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

Re: [devel] [jt] clustered fs

[Anton Farygin]

Dmitry V. Levin пишет:
> On Tue, Jun 03, 2008 at 02:54:12AM +0400, Konstantin A. Lepikhov wrote:
>> Tuesday 03, at 02:50:10 AM you wrote:
>>> On Tue, Jun 03, 2008 at 02:25:12AM +0400, Konstantin A. Lepikhov wrote:
>>>> Tuesday 03, at 01:42:29 AM you wrote:
>>> [...]
>>>>> И всё же, сколько будет стоить shared storage для такой развесистой
>>>>> клюквы?
>>>> нету там shared storage. есть clustered fs.
>>> И что там за clustered fs, на какие задачи она рассчитана, какие у неё
>>> характеристики по сравнению с локальной fs?
>>>
>> http://en.wikipedia.org/wiki/Cluster_file_system ;)
> 
> Понятно, абстрактная кластерная fs даёт абстрактную надёжность и не менее
> абстрактную производительность. :)

И кучу головной боли на сборку. Впрочем, собрать её действительно было 
бы интересно.

Re: [devel] [jt] rsync server load

[Dmitriy M. Maslennikov]

03.06.08, Alexey Gladkov<legion@altlinux.ru> написал(а):
>  Нужно посчитать, может имеет смысл прислушаться к Косте и много, недорогих
> серверов будут выгоднее.
Много недорогих всегда выгоднее. Если задача позволяет ее раскидать на
большое количество серверов.

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [devel] [jt] clustered fs

[Serge Ryabchun]

2008/6/3 Dmitry V. Levin <ldv@altlinux.org>:
>> > > > И всё же, сколько будет стоить shared storage для такой развесистой
>> > > > клюквы?
>> > > нету там shared storage. есть clustered fs.
>> >
>> > И что там за clustered fs, на какие задачи она рассчитана, какие у неё
>> > характеристики по сравнению с локальной fs?
>> >
>> http://en.wikipedia.org/wiki/Cluster_file_system ;)
>
> Понятно, абстрактная кластерная fs даёт абстрактную надёжность и не менее
> абстрактную производительность. :)

Распределенная FS и надежность понятия ортогональные. От нее требуется
производительность и объем.

-- 
sr@

Re: [devel] [jt] rsync server load

[Michael Shigorin]

On Tue, Jun 03, 2008 at 01:42:29AM +0400, Dmitry V. Levin wrote:
> И всё же, сколько будет стоить shared storage для такой
> развесистой клюквы?

Зачем там shared storage?!

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] [jt] clustered fs

[Michael Shigorin]

On Tue, Jun 03, 2008 at 03:08:32AM +0400, Dmitry V. Levin wrote:
> Понятно, абстрактная кластерная fs даёт абстрактную надёжность
> и не менее абстрактную производительность. :)

Есть и конкретный вариант:
http://www.magic.kiev.ua/ru/solutions/clusters/storage/

Если получится начать работы по интеграции в ALT раньше, 
чем это нужно нам -- тем лучше :)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] clustered fs

[Dmitry V. Levin]

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

On Tue, Jun 03, 2008 at 11:53:02AM +0300, Michael Shigorin wrote:
> On Tue, Jun 03, 2008 at 03:08:32AM +0400, Dmitry V. Levin wrote:
> > Понятно, абстрактная кластерная fs даёт абстрактную надёжность
> > и не менее абстрактную производительность. :)
> 
> Есть и конкретный вариант:
> http://www.magic.kiev.ua/ru/solutions/clusters/storage/
> 
> Если получится начать работы по интеграции в ALT раньше, 
> чем это нужно нам -- тем лучше :)

А что там нужно интегрировать в ALT?


-- 
ldv

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

Re: [devel] [jt] clustered fs

[Mykola S. Grechukh]

2008/6/3, Michael Shigorin <>:
> On Tue, Jun 03, 2008 at 03:08:32AM +0400, Dmitry V. Levin wrote:
>  > Понятно, абстрактная кластерная fs даёт абстрактную надёжность
>  > и не менее абстрактную производительность. :)
>
>
> Есть и конкретный вариант:
>  http://www.magic.kiev.ua/ru/solutions/clusters/storage/
>
>  Если получится начать работы по интеграции в ALT раньше,
>  чем это нужно нам -- тем лучше :)

таки GFS никому не нужно? :)

http://freesource.info/wiki/AltLinux/hacluster

у меня-то альт только в вмвари.

Re: [devel] clustered fs

[Michael Shigorin]

On Tue, Jun 03, 2008 at 02:27:24PM +0400, Dmitry V. Levin wrote:
> > > Понятно, абстрактная кластерная fs даёт абстрактную
> > > надёжность и не менее абстрактную производительность. :)
> > Есть и конкретный вариант:
> > http://www.magic.kiev.ua/ru/solutions/clusters/storage/
> > Если получится начать работы по интеграции в ALT раньше, 
> > чем это нужно нам -- тем лучше :)
> А что там нужно интегрировать в ALT?

Lustre, вестимо.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] lustre

[Dmitry V. Levin]

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

On Tue, Jun 03, 2008 at 06:02:51PM +0300, Michael Shigorin wrote:
> On Tue, Jun 03, 2008 at 02:27:24PM +0400, Dmitry V. Levin wrote:
> > > > Понятно, абстрактная кластерная fs даёт абстрактную
> > > > надёжность и не менее абстрактную производительность. :)
> > > Есть и конкретный вариант:
> > > http://www.magic.kiev.ua/ru/solutions/clusters/storage/
> > > Если получится начать работы по интеграции в ALT раньше, 
> > > чем это нужно нам -- тем лучше :)
> > А что там нужно интегрировать в ALT?
> 
> Lustre, вестимо.

А в чём заключается сложность?


-- 
ldv

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

Re: [devel] lustre

[Michael Shigorin]

On Tue, Jun 03, 2008 at 07:18:06PM +0400, Dmitry V. Levin wrote:
> > > > > Понятно, абстрактная кластерная fs даёт абстрактную
> > > > > надёжность и не менее абстрактную производительность. :)
> > > > Есть и конкретный вариант:
> > > > http://www.magic.kiev.ua/ru/solutions/clusters/storage/
> > > > Если получится начать работы по интеграции в ALT раньше, 
> > > > чем это нужно нам -- тем лучше :)
> > > А что там нужно интегрировать в ALT?
> > Lustre, вестимо.
> А в чём заключается сложность?

Эт лучше sr@ спрашивать, я преимущественно слышу отзывы
и сужу только по ним.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] lustre

[Dmitry V. Levin]

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

On Tue, Jun 03, 2008 at 11:21:26PM +0300, Michael Shigorin wrote:
> On Tue, Jun 03, 2008 at 07:18:06PM +0400, Dmitry V. Levin wrote:
> > > > > > Понятно, абстрактная кластерная fs даёт абстрактную
> > > > > > надёжность и не менее абстрактную производительность. :)
> > > > > Есть и конкретный вариант:
> > > > > http://www.magic.kiev.ua/ru/solutions/clusters/storage/
> > > > > Если получится начать работы по интеграции в ALT раньше, 
> > > > > чем это нужно нам -- тем лучше :)
> > > > А что там нужно интегрировать в ALT?
> > > Lustre, вестимо.
> > А в чём заключается сложность?
> 
> Эт лучше sr@ спрашивать, я преимущественно слышу отзывы
> и сужу только по ним.

Он ведь тоже здесь?  Давайте спросим.


-- 
ldv

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

Re: [devel] lustre

[Serge Ryabchun]

2008/6/4 Dmitry V. Levin <ldv@altlinux.org>:
> On Tue, Jun 03, 2008 at 11:21:26PM +0300, Michael Shigorin wrote:
>> On Tue, Jun 03, 2008 at 07:18:06PM +0400, Dmitry V. Levin wrote:
>> > > > > > Понятно, абстрактная кластерная fs даёт абстрактную
>> > > > > > надёжность и не менее абстрактную производительность. :)
>> > > > > Есть и конкретный вариант:
>> > > > > http://www.magic.kiev.ua/ru/solutions/clusters/storage/
>> > > > > Если получится начать работы по интеграции в ALT раньше,
>> > > > > чем это нужно нам -- тем лучше :)
>> > > > А что там нужно интегрировать в ALT?
>> > > Lustre, вестимо.

Не нужно ее интегрировать в ALT ;-).
Это сильно специфическая весчь, которая нужна в кластерах или рядом с
ними. Грузить этой спецификой дистрибутив общего назначения не нужно.

>> > А в чём заключается сложность?
>>

В том, что это весчь не "поставил и забыл", а требующая четкого понимания
того, что делается. Иначе вполне возможна ситуация разноса вребезги
файловой системы на сотни терабайт, а то и петабайт. Брать на себя
ответственность за такое дистрибутиву общего назначения нельзя.
Не говоря уже о куче патчей к ядру, поддержке ограниченного количества ядер,
серверная часть застряла на 2.6.18, нестыковка с openvz, возможная потеря
данных при рассинхронизации версий клиента и сервера, низкая производительность
на 1GigE, особенно на каталогах с тысячами мелких файлов, а покажите мне
сетку на InfiniBand-е, непонятки с ее судьбой после покупки SUN-ом, ну
и так дальше.
Короче, есть куча проектов, где применение Lustre даст отличную
производительность
и где она нужна, но в сотни раз больше, где она и нафиг не сдалась.

-- 
Рябчун Сергей <serge.ryabchun@gmail.com>

Re: [devel] lustre

[Michael Shigorin]

On Wed, Jun 04, 2008 at 03:15:15PM +0300, Serge Ryabchun wrote:
> >> > > > А что там нужно интегрировать в ALT?
> >> > > Lustre, вестимо.
> Не нужно ее интегрировать в ALT ;-).  Это сильно специфическая
> весчь, которая нужна в кластерах или рядом с ними. Грузить этой
> спецификой дистрибутив общего назначения не нужно.

В смысле kernel-image-hpc или вообще отдельное.
Не в std-*, естественно ;-)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] comprehensive rsyncability test

[Alexey Tourbin]

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

On Tue, Jun 03, 2008 at 12:24:51AM +0400, Dmitry V. Levin wrote:
> On Sun, Jun 01, 2008 at 02:18:58PM +0400, Alexey Tourbin wrote:
> [...]
> > Таким образом, я считаю, что в вопросе "rsyncable deflate vs LZMA"
> > ни один из вариантов не имеет решающих преимуществ.
> 
> У меня сложилось то же самое мнение.  Есть две разные категории
> пользователей репозитория, для которых выбор вариантов будет различным.
> Давайте попробуем прикинуть, что предпочтительнее в кратко-, средне- и
> долгосрочной перспективе.

Я склоняюсь в пользу LZMA.

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

Re: [devel] lustre

[Anton Farygin]

Michael Shigorin пишет:
> On Wed, Jun 04, 2008 at 03:15:15PM +0300, Serge Ryabchun wrote:
>>>>>>> А что там нужно интегрировать в ALT?
>>>>>> Lustre, вестимо.
>> Не нужно ее интегрировать в ALT ;-).  Это сильно специфическая
>> весчь, которая нужна в кластерах или рядом с ними. Грузить этой
>> спецификой дистрибутив общего назначения не нужно.
> 
> В смысле kernel-image-hpc или вообще отдельное.
> Не в std-*, естественно ;-)

И тем более не на FTP.

Re: [devel] comprehensive rsyncability test

[Anton Farygin]

Alexey Tourbin пишет:
> On Tue, Jun 03, 2008 at 12:24:51AM +0400, Dmitry V. Levin wrote:
>> On Sun, Jun 01, 2008 at 02:18:58PM +0400, Alexey Tourbin wrote:
>> [...]
>>> Таким образом, я считаю, что в вопросе "rsyncable deflate vs LZMA"
>>> ни один из вариантов не имеет решающих преимуществ.
>> У меня сложилось то же самое мнение.  Есть две разные категории
>> пользователей репозитория, для которых выбор вариантов будет различным.
>> Давайте попробуем прикинуть, что предпочтительнее в кратко-, средне- и
>> долгосрочной перспективе.
> 
> Я склоняюсь в пользу LZMA.

Алексей, а нельзя ли алгоритмом сжатия управлять из спека ? По умолчанию 
поставить, например, LZMA, а в спек-файле дать возможность заменить на 
другой.

Re: [devel] comprehensive rsyncability test

[Alexey Tourbin]

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

On Wed, Jun 04, 2008 at 04:49:25PM +0400, Anton Farygin wrote:
> 
> 
> Alexey Tourbin пишет:
> >On Tue, Jun 03, 2008 at 12:24:51AM +0400, Dmitry V. Levin wrote:
> >>On Sun, Jun 01, 2008 at 02:18:58PM +0400, Alexey Tourbin wrote:
> >>[...]
> >>>Таким образом, я считаю, что в вопросе 
> >>>"rsyncable deflate vs LZMA"
> >>>ни один из вариантов не имеет решающих 
> >>>преимуществ.
> >>У меня сложилось то же самое мнение.  
> >>Есть две разные категории
> >>пользователей репозитория, для которых 
> >>выбор вариантов будет различным.
> >>Давайте попробуем прикинуть, что 
> >>предпочтительнее в кратко-, средне- и
> >>долгосрочной перспективе.
> >
> >Я склоняюсь в пользу LZMA.
> 
> Алексей, а нельзя ли алгоритмом сжатия 
> управлять из спека ? По умолчанию 
> поставить, например, LZMA, а в спек-файле 
> дать возможность заменить на другой.

Можно.  Управляется через %_source_payload и %_binary_payload
в /usr/lib/rpm/macros.  Соответственно, можно будет в spec-файле
переопределить

%define _source_payload w2.lzdio
%define _binary_payload w2.lzdio

или же передать опции

rpmbuild --define '_source_payload w2.lzdio' --define '_binary_payload w2.lzdio'

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

Re: [devel] lustre

[Andrey Brindeyev]

Anton Farygin wrote:
>>
>> В смысле kernel-image-hpc или вообще отдельное.
>> Не в std-*, естественно ;-)
> И тем более не на FTP.
Интересно почему?

Кстати, по поводу самой фс согласен - специфичный софт, его поддержка 
требует отдельного человека. И вообще это на отдельный проект тянет. HPC 
distro.

WBR, Andrey.

Re: [devel] lustre

[Andrey Brindeyev]

Anton Farygin wrote:
>>
>> В смысле kernel-image-hpc или вообще отдельное.
>> Не в std-*, естественно ;-)
> И тем более не на FTP.
Интересно почему?

Кстати, по поводу самой фс согласен - специфичный софт, его поддержка 
требует отдельного человека. И вообще это на отдельный проект тянет. HPC 
distro.

WBR, Andrey.

Re: [devel] lustre

[Anton Farygin]

Andrey Brindeyev пишет:
> Anton Farygin wrote:
>>>
>>> В смысле kernel-image-hpc или вообще отдельное.
>>> Не в std-*, естественно ;-)
>> И тем более не на FTP.
> Интересно почему?
> 
> Кстати, по поводу самой фс согласен - специфичный софт, его поддержка 
> требует отдельного человека. И вообще это на отдельный проект тянет. HPC 
> distro.

Типа этого?
http://ftp.altlinux.org/pub/people/inger/hpc/

Rgds,
Rider

Re: [devel] lustre

[Alexander Bokovoy]

4 июня 2008 г. 18:17 пользователь Andrey Brindeyev <abr@altlinux.ru> написал:
> Anton Farygin wrote:
>>>
>>> В смысле kernel-image-hpc или вообще отдельное.
>>> Не в std-*, естественно ;-)
>>
>> И тем более не на FTP.
>
> Интересно почему?
>
> Кстати, по поводу самой фс согласен - специфичный софт, его поддержка
> требует отдельного человека. И вообще это на отдельный проект тянет. HPC
> distro.
HPC дистрибутив есть, в рамках совместного проекта с Т-платформами.
Но там, насколько я помню, panfs.
-- 
/ Alexander Bokovoy

Re: [devel] lustre

[Serge Ryabchun]

2008/6/4 Anton Farygin <rider@altlinux.com>:
>> требует отдельного человека. И вообще это на отдельный проект тянет. HPC
>> distro.
>
> Типа этого?
> http://ftp.altlinux.org/pub/people/inger/hpc/

Нее, типа этого
http://h20219.www2.hp.com/HPC/cache/276636-0-0-0-121.html

-- 
Рябчун Сергей <serge.ryabchun@gmail.com>

Re: [devel] lustre

[Andrey Brindeyev]

Anton Farygin wrote:
>> Кстати, по поводу самой фс согласен - специфичный софт, его поддержка 
>> требует отдельного человека. И вообще это на отдельный проект тянет. 
>> HPC distro.
> Типа этого?
> http://ftp.altlinux.org/pub/people/inger/hpc/
Типа. Кстати, scaling как проверяли? Оно будет жить на >1000 узлов?

Re: [devel] comprehensive rsyncability test

[Michael Shigorin]

On Wed, Jun 04, 2008 at 05:04:12PM +0400, Alexey Tourbin wrote:
> > Алексей, а нельзя ли алгоритмом сжатия управлять из спека ?
> > По умолчанию поставить, например, LZMA, а в спек-файле дать
> > возможность заменить на другой.
> Можно.  Управляется через %_source_payload и %_binary_payload в
> /usr/lib/rpm/macros.  Соответственно, можно будет в spec-файле
> переопределить
> 
> %define _source_payload w2.lzdio
> %define _binary_payload w2.lzdio
> 
> или же передать опции
> 
> rpmbuild --define '_source_payload w2.lzdio' --define '_binary_payload w2.lzdio'

Ух ты, так остаётся выбрать разумный дефолт (продолжает казаться,
что это LZMA) и менять его на rsyncable для того, что известно
как таковое (те же ядро, иксы, openoffice, firefox, cups и что 
большого ещё регулярно нуждается в апдейтах, которые затрагивают
малую часть пакета).

Возможно, по ходу пьесы добавив соответствующий тест в repocop,
набрав статистику и раздав рекомендаций (или сразу патчиков).

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] comprehensive rsyncability test

[Alexey Tourbin]

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

On Wed, Jun 04, 2008 at 08:37:31PM +0300, Michael Shigorin wrote:
> > %define _source_payload w2.lzdio
> > %define _binary_payload w2.lzdio
> > 
> > или же передать опции
> > 
> > rpmbuild --define '_source_payload w2.lzdio' --define '_binary_payload w2.lzdio'
> 
> Ух ты, так остаётся выбрать разумный дефолт (продолжает казаться,
> что это LZMA) и менять его на rsyncable для того, что известно
> как таковое (те же ядро, иксы, openoffice, firefox, cups и что 
> большого ещё регулярно нуждается в апдейтах, которые затрагивают
> малую часть пакета).

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

Например, в одном из предыдущих писем я высянил, что rsyncable
синхронизация firefox-2.0.0.13-alt1.x86_64.rpm -> firefox-2.0.0.14-alt1.x86_64.rpm
экономит примерно половину размера 10.4M/2 = 5.2M.  При этом если
пережать firefox в 'lzma -5', то его размер будет 7.6M, и экономия
относительно прежнего размера составит 2.8M без всякого rsync'а.
Так что даже при minor update'ах выгода от rsync может быть умеренной
и сопоставимой с непосредственной выгодой от LZMA.

> Возможно, по ходу пьесы добавив соответствующий тест в repocop,
> набрав статистику и раздав рекомендаций (или сразу патчиков).

No-no-no.  Не стоит в порядке самодеятельности крутить эти ручки.

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

Re: [devel] comprehensive rsyncability test

[Dmitry V. Levin]

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

On Wed, Jun 04, 2008 at 05:04:12PM +0400, Alexey Tourbin wrote:
> On Wed, Jun 04, 2008 at 04:49:25PM +0400, Anton Farygin wrote:
> > 
> > 
> > Alexey Tourbin пишет:
> > >On Tue, Jun 03, 2008 at 12:24:51AM +0400, Dmitry V. Levin wrote:
> > >>On Sun, Jun 01, 2008 at 02:18:58PM +0400, Alexey Tourbin wrote:
> > >>[...]
> > >>>Таким образом, я считаю, что в вопросе 
> > >>>"rsyncable deflate vs LZMA"
> > >>>ни один из вариантов не имеет решающих 
> > >>>преимуществ.
> > >>У меня сложилось то же самое мнение.  
> > >>Есть две разные категории
> > >>пользователей репозитория, для которых 
> > >>выбор вариантов будет различным.
> > >>Давайте попробуем прикинуть, что 
> > >>предпочтительнее в кратко-, средне- и
> > >>долгосрочной перспективе.
> > >
> > >Я склоняюсь в пользу LZMA.
> > 
> > Алексей, а нельзя ли алгоритмом сжатия 
> > управлять из спека ? По умолчанию 
> > поставить, например, LZMA, а в спек-файле 
> > дать возможность заменить на другой.
> 
> Можно.  Управляется через %_source_payload и %_binary_payload
> в /usr/lib/rpm/macros.  Соответственно, можно будет в spec-файле
> переопределить
> 
> %define _source_payload w2.lzdio
> %define _binary_payload w2.lzdio
> 
> или же передать опции
> 
> rpmbuild --define '_source_payload w2.lzdio' --define '_binary_payload w2.lzdio'

Собственно говоря, эти интерфейсы управления доступны давно.


-- 
ldv

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

Re: [devel] lustre

[Anton Farygin]

Andrey Brindeyev пишет:
> Anton Farygin wrote:
>>> Кстати, по поводу самой фс согласен - специфичный софт, его поддержка 
>>> требует отдельного человека. И вообще это на отдельный проект тянет. 
>>> HPC distro.
>> Типа этого?
>> http://ftp.altlinux.org/pub/people/inger/hpc/
> Типа. Кстати, scaling как проверяли? Оно будет жить на >1000 узлов?

Вот как раз сегодня проверяют. Но жить будет, чего б ему не жить...

Re: [devel] comprehensive rsyncability test

[Michael Shigorin]

On Wed, Jun 04, 2008 at 10:24:55PM +0400, Alexey Tourbin wrote:
> Это только так кажется, что апдейты затрагивают малую часть пакета.

Эээ... имел в виду "контента" и забыл, что ты писал про влияние
метаданных.

> > Возможно, по ходу пьесы добавив соответствующий тест в repocop,
> > набрав статистику и раздав рекомендаций (или сразу патчиков).
> No-no-no.  Не стоит в порядке самодеятельности крутить эти ручки.

Дык как раз чтоб подальше от самодеятельности ;-)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] comprehensive rsyncability test

[Anton V. Boyarshinov]

> как таковое (те же ядро, иксы, openoffice, firefox, cups и что 
> большого ещё регулярно нуждается в апдейтах, которые затрагивают
> малую часть пакета).
Но как раз "openoffice, firefox" это именно то, что мечтается пожать посильнее ;)) А иксы на много пакетов побиты (если говорит о бинарных пакетах, во всяком случае)

Re: [devel] lustre

[Sergey Zhumatiy]

> HPC дистрибутив есть, в рамках совместного проекта с Т-платформами.
> Но там, насколько я помню, panfs.

  Добавить туда более другие решения (lustre и др.) будет разумно.
Panassass - вещь очень крутая, но и очень дорогая. Не всем по карману. А
AltLinux HPC должен быть хорошо тиражируем на решения в области HPC.

-- 
  С уважением
                                                   Serg.

Re: [devel] lustre

[Alexander Bokovoy]

5 июня 2008 г. 13:04 пользователь Sergey Zhumatiy <serg@parallel.ru> написал:
>> HPC дистрибутив есть, в рамках совместного проекта с Т-платформами.
>> Но там, насколько я помню, panfs.
>
>  Добавить туда более другие решения (lustre и др.) будет разумно.
> Panassass - вещь очень крутая, но и очень дорогая. Не всем по карману. А
> AltLinux HPC должен быть хорошо тиражируем на решения в области HPC.
Я бы различал "добавить" и "обеспечить поддержку". Все эти системы
требуют достаточно серьезных вложений времени и человеческих знаний
для того, чтобы обеспечить надежность их работы. Поэтому я лично такую
работу волонтерским образом не делал бы.

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

-- 
/ Alexander Bokovoy