On Fri, 5 Jan 2001, Francois Deppierraz wrote:
> Est-ce normal qu'en �crivant des donn�es presque incompressibles
> (r�sultat d'un gzip -9) sur une bande avec la compression mat�riel
> activ�e j'arrive � copier 1'623 Mo alors que sans compression mat�riel
> j'arrive � en copier 1'923 Mo ?
Oui, c'est `normal'. Je ne connais pas les d�tails d'impl�mentation des
chips de compression, mais:
- c'est embarqu� et c'est peu puissant
- c'est sauf erreur du LZW qui sauf erreur a un tr�s mauvais
comportement avec des donn�es al�atoires (== compress�es avec
un bon algorithme comme gzip)
> Est-ce que la m�thode suivante est correcte pour tester la capacit�
> d'une bande ?
>
> slipknot:/home/francois# time (for i in `find /usr`; do cat
> /tmp/truc.tar.gz; done) | dd of=/dev/nst0 obs=1048576
oui, � 4096 bytes pr�s (PIPE_BUF). On suppose que truc.tar.gz >> taille du
buffer de compression du drive. A part �a, ton obs est �norme :)
PS: moi j'aurais �crit sans me poser de question et j'aurais �valu� la
capacit� � la lecture (avec bs=32k, ce qui n'a aucune importance si setblk
est 512, non z�ro)
> Est-ce que j'ai meilleur temps d'utiliser seulement la compressions
> mat�riel ? Seulement la compression software ? Ou les deux (je pense
> pas...) ?
Si l'on peut se le permettre, le mieux est de supprimer dans tous les cas
la compression mat�rielle: la capacit� est alors plus pr�visible, la
compression est meilleure (gzip -9 est meilleur), et l'interop�rabilit�
plus grande.
--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question.
