Re: lug-bg: влияние на размера на блока

[George Danchev <danchev@xxxxxxxxx>]

On Wednesday 25 August 2004 13:17, Peter Pentchev wrote:
--cut--
> Какво точно искаш да кажеш с това 'да получи на вход'?  Ако имаш предвид
> да се даде на tar опция -b 1800, така че то да прави write() на парчета
> от 900KB и bzip2 да получава по 900KB при всеки read(), аз виждам два
> възможни сериозни проблема с това:

Мда, точно така, не виждам нищо лошо в:
tar cf - dir -b 1800 | bzip2 > dir.tar.bz2
макар, че чак сега се замислям над това и до сега не съм го ползвал.
Но сега го изтествах няколко/доста пъти и с дифф проверих наистина ли 
оригинала се запазва след горното архивиране/компресиране и 
декомпресиране/деархивиране. Ми всичко е ОК.
Нямам време да тествам с time и да гледам compress ratio-то на горното с и без 
разни стойности на -b, но -b 1800 приляга според мен идеално на -9 на 
bzip2 ;-)

> 1. Не съм сигурен, че write() на 900KB ще бъде atomic; много по-вероятно
>    е то или да върне short byte count - да върне стойност, по-малка от
>    899981, така че да трябва tar след това да направи втори write() на
>    остатъка, или да каже на tar, че всичко е наред, обаче всъщност да
>    подаде на bzip2 *няколко* по-малки парчета.  И в двата случая bzip2
>    няма да получи 899981 байта наведнъж, ако това е, което си имал
>    предвид.

наистина в нашия случай писането в пайпа може да се окаже атомично или 
неатомично (според зависи от няколко неща е). Но теб какво те притеснява това 
дали е или не е атомично. Загуба на данни няма да имаш. Профански погледнато 
или директно тъп въпрос: Ако имаше подобна опасност защо я няма описана като 
CAVIATS/BUG в мана ;-)

> 2. Всъщност това е доста подобно на първото - при положение, че tar и
>    bzip2 обикновено се използват в pipe (tar -cf - | bzip2 > foo или
>    tar -cjf foo.tar.bz2, като при втория вариант tar сам изпълнява bzip2
>    и подава входа чрез pipe), то според мен е много вероятно наистина
>    една pipe да не може да поеме 899981 байта наведнъж.  Не съм сигурен
>    за Linux, но в момента гледам src/sys/kern/sys_pipe.c за FreeBSD
>    5.3-BETA1 as of today и ми изглежда, че максималният размер на нещо,
>    което може да мине atomically през една pipe, е BIG_PIPE_SIZE, което
>    всъщност е 64KB.  При това положение дори и теоретично няма начин tar
>    да подаде на bzip2 един цял блок данни от 899981 байта, т.е. няма
>    начин bzip2 да направи read() и с *един* read() да прочете 899981
>    байта :(

Според мен ядрото няма да бута в пайпа наведнъж всичките 899981 байта ;-) 
горната команда ще мине и на фрийсби, почти съм сигурен... просто тези 899981 
байта ще бъдат подадени на по-малки части и това си е работа на ядрото мисля 
да контролира двата края на пайпа и колко влиза и колко излиза в и от тях.

Гледам glibc docs, че са ми подръка ...
Macro: int PIPE_BUF
The uniform system limit (if any) for the number of bytes that can be written 
atomically to a pipe. 

Явно този  uniform system limit (if any) ще зависи от ядрото, ако въобще го 
има. Ето какво имам аз.

cat /usr/include/linux/limits.h | grep PIPE
#define PIPE_BUF        4096    /* # bytes in atomic write to a pipe */

в ядрото не ми се рови ;-) 
После дори се казва, че няколко процеса могат да пишат едновременно ...
If multiple processes are writing to the same pipe simultaneously, output from 
different processes might be interleaved in chunks of this size (сайза е 
PIPE_BUF). 

до тук само красиви неща виждам аз и нищо лошо. 

> > > Поне както аз виждам нещата, единственият случай, в който размерът на
> > > блоковете на bzip2 ще има значение, ще бъде този:
> > >
> > > 1. имаш множество малки файлчета;
> > > 2. слагаш голям размер на блок за tar, така че изходът на tar има
> > >    доста повече нули, отколкото истински данни, *и*
> > > 3. слагаш *малък* размер на блок за bzip2
> >
> > при малък размер ще reblock-ваш което е излишен performance impact.
> > нека си постъпват на входа големи (900к) за да не реблокваш и да
> > компресваш най-изгодно.
>
> Да, знам, че по принцип изобщо не е добра идея на bzip2 да му се дава
> малък block size.  Идеята за block size от 100KB беше само за да
> илюстрирам единствения случай, в който според мен можеше да има
> намаляване на производителността на tar/bzip2.  Според мен също няма
> никаква, ама никаква причина (освен ако 8MB памет не са много) изобщо
> някога да се използва bzip2 block size, по-малък от 900KB.  Looks like
> we're in violent agreement on this one :)  Ако съм те разбрал правилно,
> единственото, по което мненията ни малко се различаваха, беше, че ми се
> стори, че искаш да кажеш, че най-добрият вариант ще бъде да се укаже на
> tar да използва блокове по 900KB, защото така са най-удобни на bzip2 -
> само че това просто не е възможно, или по-скоро не е възможно да донесе
> исканото повишаване на производителността :(

мда, мисля си, че така е най-добре докато някой не ме опровергае ;-)

-- 
pub 4096R/0E4BD0AB  2003-03-18  <keyserver.bu.edu ; pgp.mit.edu>
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 
============================================================================
A mail-list of Linux Users Group - Bulgaria (bulgarian linuxers).
http://www.linux-bulgaria.org - Hosted by Internet Group Ltd. - Stara Zagora
To unsubscribe: http://www.linux-bulgaria.org/public/mail_list.html
============================================================================