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

[George Danchev <danchev@xxxxxxxxx>]

On Wednesday 25 August 2004 15:14, Peter Pentchev wrote:
> On Wed, Aug 25, 2004 at 02:53:42PM +0300, George Danchev wrote:
> > 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
>
> Значи да попитам пак: смяташ, че ако размерът на изходния блок на tar е
> равен на размера на входния блок на bzip2, това ще доведе до повишаване
> на производителността, така ли?  Един малко тъп въпрос: защо?  Т.е. как?
> Т.е. какво точно смяташ, че ще се подобри?

ами точно както си си отговорил по-долу, имах предвид да се намали сискол 
овърхеда от реблокинг при bzip2.

> Единственото, което на мен ми се струва възможно да се подобри, е това
> bzip2 да си получава входа с по-малко работа, т.е. с по-малко syscalls,
> т.е. да получава по 900KB (или по-точно по 899981 байта) при всяко
> извикване на read() - а това е *точно* това, което смятам, че няма начин
> да стане :)  Ако имаш някаква друга идея за това как точно ще се подобри
> работата на bzip2, ако на tar му зададеш -b 1800, казвай!

имаме: block = [record size (кратно на 512)] x [blocking factor]
това 899981 за сега нямам идея защо се получава, но се получава при разни 
стойности на -b:

tar cf - dir -b 18 | bzip2 -vv9 > dir.tar.bz2
  (stdin):
    block 1: crc = 0x57a34772, combined CRC = 0x57a34772, size = 899981
    block 2: crc = 0x3af72ef3, combined CRC = 0x95b1a017, size = 899981
    too repetitive; using fallback sorting algorithm
--cut--
    too repetitive; using fallback sorting algorithm
    block 14: crc = 0xebffb305, combined CRC = 0xa95993f8, size = 63461
    too repetitive; using fallback sorting algorithm


tar cf - dir -b 1800 | bzip2 -vv9 > dir.tar.bz2
  (stdin):
    block 1: crc = 0x57a34772, combined CRC = 0x57a34772, size = 899981
    block 2: crc = 0x3af72ef3, combined CRC = 0x95b1a017, size = 899981
    too repetitive; using fallback sorting algorithm
    block 3: crc = 0xab13839d, combined CRC = 0x8070c3b2, size = 899981
--cut--
    too repetitive; using fallback sorting algorithm
    block 13: crc = 0xc87a56ae, combined CRC = 0xa153107e, size = 899981
    too repetitive; using fallback sorting algorithm
    block 14: crc = 0x49894d75, combined CRC = 0x b2f6d88, size = 77556


навсякъде започваме с 899981 (което не е кратно и на 512) и за последното 
каквото остане... да не би към него добавя и CRC сумата за да стане към 
900096 (1759x512) ... 

разбира се вече при bzip2 --fast  намалява размера на блока:
 tar cf - dir -b 18 | bzip2 --fast -vv9 > dir.tar.bz2
  (stdin):
    block 1: crc = 0xd784b69c, combined CRC = 0xd784b69c, size = 99981

Да знаеш, че това дето е посочено като 900000 байта в мана на bzip2 не е точно 
толко а е кратно на 512, това идва и от горната формула за bzip2 иска record 
size да е кратен на 512, така, а нито 900000, нито 899981 са му кратни. Има 
нещо което не отчитаме тука за размера на блока ;-)

> А на всичкото отгоре тук има и допълнителен момент: числото 899981 съм
> го взел от това, което показва bzip2 -vv9 largefile.  Т.е. блоковете на
> bzip2 всъщност *не са* по 900KB, а са по 899981 байта, и на практика
> няма начин да убедиш tar да прави точно толкова големи блокове, колкото
> bzip2 иска, така че цялата тази история е още малко безсмислена май...
>
> > макар, че чак сега се замислям над това и до сега не съм го ползвал.
> > Но сега го изтествах няколко/доста пъти и с дифф проверих наистина ли
> > оригинала се запазва след горното архивиране/компресиране и
> > декомпресиране/деархивиране. Ми всичко е ОК.
>
> Нее, като говоря за сериозни проблеми нямам предвид загуба на данни :)
> Май пак не се изразих както трябва :)  Имам предвид причини това да не
> доведе до повишаване на производителността.
>
> > Нямам време да тествам с time и да гледам compress ratio-то на горното с
> > и без разни стойности на -b, но -b 1800 приляга според мен идеално на -9
> > на bzip2 ;-)
>
> И пак питам - как и защо? :)

Да се намали сискол овърхеда от реблокинг при bzip2. Това е единственото което 
можем да се опитаме да си спестим според мен.

> > Според мен ядрото няма да бута в пайпа наведнъж всичките 899981 байта ;-)
> > горната команда ще мине и на фрийсби, почти съм сигурен... просто тези
> > 899981 байта ще бъдат подадени на по-малки части и това си е работа на
> > ядрото мисля да контролира двата края на пайпа и колко влиза и колко
> > излиза в и от тях.
>
> Така де, така - и точно затова ядрото и от двата края на пайпа не
> поддържа блокове по 899981, следователно bzip2 няма начин да прочете
> наведнъж 899981 байта - и с какво ще се подобри работата му тогава?
> Особено при положение, че 1800 * 512 != 899981 :)

значи първо не сме сигурни дали tar и bzip2  write()-ват и read()-ват цели 
блокове или цели записи или части от записи от по 512 байта. После ако за 
размер на блокове и записи бъдат поискани много големи стойности май не знаем 
какви трикове прави ядрото за да ги прекара през пайпа, което да остава 
невидимо за userlanda. Важното е, че и двете приложения знаят къде започва и 
къде свършва даден блок. Гледам, че за стойности на блока около 900000, пак 
се изписва size = 899981. 
tar cf - dir -b 1 --record-size 899584 | bzip2 -vv9 > dir.tar.bz2
tar cf - dir -b 1 --record-size 900096 | bzip2 -vv9 > dir.tar.bz2
  (stdin):
    block 1: crc = 0x57a34772, combined CRC = 0x57a34772, size = 899981
    block 2: crc = 0x3af72ef3, combined CRC = 0x95b1a017, size = 899981
    too repetitive; using fallback sorting algorithm

tar cf - dir -b 1 --record-size 819200 | bzip2 -vv9 > dir.tar.bz2
  (stdin):
    block 1: crc = 0x57a34772, combined CRC = 0x57a34772, size = 899981
    block 2: crc = 0x3af72ef3, combined CRC = 0x95b1a017, size = 899981

Та това може да не е размера на блока който получава bzip2, а който обработва 
явно след реблокване. Предлагам да не гадеам повече. 
Освен това, не е казано, че трябва двете приложения да се пайпват, ако имаме 
съмнения, че предаването в пайпа може да се бави поради разни причини (tar 
--options; bzip2 --options)

-- 
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
============================================================================