[gull] Question sur les performances de DDS-3

[Marc SCHAEFER]

On Fri, Oct 20, 2006 at 10:42:40PM +0200, Alexis Domjan wrote:
>    # tar cf - . | gzip -1 | buffer -s 10k -S 100k | dd of=/dev/nst0 obs=32k

Recommandé:

   mt -f /dev/nst0 datcompression 0 # supprimer la compression de la compression
   mt -f /dev/nst0 rewind
   tar -cf - . | gzip -1 | buffer -S 1048576 -s 32768 -o /dev/nst0

alternative:

   mt -f /dev/nst0 datcompression 2 # de mémoire
   mt -f /dev/nst0 rewind
   tar -cf - . | buffer -S 1048576 -s 32768 -o /dev/nst0

On peut aussi enlever le buffer du pipe et écrire directement:

   tar -b 64 -cf /dev/nst0

cela peut augmenter la performance.

Noter que la version *sans* gzip n'implémente pas de CRC, on ne pourra
donc pas auditer la cassette (sinon par un tar --compare).  tar a bien
des checksums sur les méta-données, mais pas sur les données.

>    511237K,        842K/s
>    dd: writing `/dev/nst0': Invalid argument

on dirait un problème de blocage (taille de bloc), cf dmesg.

Par défaut beaucoup de lecteurs ont 512 bytes de taille de bloc (cf mt
status). Ce qui signifie que toute écriture doit être un multiple de 512
bytes. Cela est en général le cas, mais il se peut que le dernier bloc
(en particulier avec gzip) ne soit pas un tel multiple.

Solutions:
   - mt -f /dev/nst0 setblk 0 # taille de bloc variable, mais on la fixe
                              # par -b 64 ou buffer à 32k jusqu'au
                              # dernier, qui lui peut être plus petit

   - s'arranger pour que gzip rajoute du vide (cf man gzip, et option -z
     de tar)

   - s'arranger pour que buffer ou dd rajoute du vide (mais attention!
     dd est très dangereux à ce niveau, car il complétera chaque bloc!
     dans un pipe, on a MAX_PIP_SIZE=4k, pas 32k!!)

> De temps à autre le drive semble se "réajuster" puisqu'il émet un son
> différent et le transfert s'interrompt un instant. Est-ce que c'est un

Probablement un problème de vitesse d'écriture, voire de nettoyage.
J'ai un outil (binaire uniquement, je devrais le réécrire) pour compter
les erreurs logicielles.  Il me semble qu'Amanda le fait par défaut.

Un lecteur DAT/DDS a une tête de lecture qui peut lire ce qu'il vient
d'écrire.  S'il n'arrive pas à lire, il revient en arrière, écrit des
`MAUVAIS-MAUVAIS' et réécrit la zone plus loin. On compte cela comme
une erreur logicielle (soft error) à l'écriture.

A la lecture, une zone peut être *devenue* illisible. Il peut revenir en
arrière, adapter la vitesse, faire jouer des déplacements de
synchronisation et éventuellement appliquer un code de correction
d'erreur.  Si cela fonctionne malgré toutes les embûches, il compte cela
comme erreur logicielle à l'écriture.

Un nombre élevé d'être soft (logicielles) indique, par ordre de
priorité croissante:

   - le lecteur n'est pas nettoyé suffisamment souvent
   - la cassette est défectueuse et devrait être jetée
   - le lecteur n'arrive pas à streamer, l'ordinateur ne collecte pas
     les données assez vite ou n'a pas assez de cache (disque ou cf
     commande buffer)
   - le lecteur est tellement sale qu'il n'arrive plus à se nettoyer
     (ouvrir, nettoyer la tête *délicatement!!!* avec la face
      inscriptible d'un postit)
   - le lecteur est défectueux (durée de vie, selon les modèles et
     le taux d'utilisation. Certains lecteurs supportent max 20%
     duty-cycle)

Autres conseils:
   - pas d'imprimante laser à proximité!
   - pas de fumeurs!
   - pas de changement de température brusque en utilisation (fenêtre
     ouverte, etc)
   - pas de vibrations

En bref, un chantier n'est pas le bon endroit :)

> comportement normal du drive ? Pour information mon lecteur est un sony
> sdt-9000. (L'erreur de dd (invalid argument) est-elle ``normale'' ?)

Bonne bête, quoiqu'un peu fragile. Sony a eu quelques ratés avec ce
modèle au niveau du firmware.  Non, l'erreur n'est pas attendue
ici.  Il doit me rester une cassette de mise à jour du firmware qqpart,
mais je ne pense pas que c'est nécessaire.

> Autre question; y a-t-il un moyen de savoir l'efficacité de la
> compression matérielle utilisée par le lecteur ? Par exemple savoir la
> place que prend effectivement un fichier pour sa taille effective ?

On le déduit de la vitesse.  Je n'ai plus les débits en tête, mais
disons

standard taille longueur vitesse modèle Sony
         n.c.   cassette
DDS-1     1.5GB   60m    300 kilobyte/s   SDT-1000 (de mémoire)
DDS-2     2/4GB   90m/120m    300/600 kilobyte/s   SDT-5/7000
DDS-3    12GB    120m    1 MByte/s        SDT-9000
DDS-4    20GB    150m    2 MByte/s        SDT-11000
DDS-72   36GB           ?      (propriétaire HP)

(voir aussi http://www.backupcentral.com/)

Avec une machine dédiée correcte, j'obtenais facilement 4 MByte/s pour
une sauvegarde non compressée avec la compression matérielle sur un
DDS-4.  En écrivant des zéros, jusqu'à 8-10 MByte/s (très utile). Mais
dans ce cas le lecteur était complètement arrêté, ne s'allumant que tous
les quelques gigabytes pour probablement écrire un compteur RLE :>

Mais en général je préfère faire la sauvegarde, la compresser, la couper
en morceaux puis la déposer sur cassettes (via un cache disque, pas
forcément énorme, on peut faire le tout en parallèle comme le fait
Amanda, afbackup ou bakula).  La compression par le CPU de la machine
(même une machine d'il y a 6 ans) dépassera forcément la compression
matérielle d'un SDT-9000 embarqué et conçu en 1997.

Amanda est très complexe; afbackup a quelques fonctions dangereuses. Je
crois que -- sans l'avoir utilisé -- bakula est une bonne solution pour
la sauvegarde multi-machines.  Pour une sauvegarde d'une machine, ce qui
précède suffit. Vérifier la sauvegarde (--compare) et de temps en temps
tester les cassettes.

En plus comme je l'ai dit, l'avantage de gzip c'est le CRC sur les
données, utile surtout en cas d'audit quelques mois plus tard (le drive
a un CRC interne, mais j'ai déjà vu des choses bizarres se passer avec
la compression activée avec de vieux firmwares SDT-9000).

-- 
Je lis les messages bien formatés. N'abusez pas du Cc:. Texte == efficace.
Citer n'est pas concaténer. Editez vos messages, ça gagne du temps.
Marc se met au blog `-o ro': http://www.alphanet.ch/schaefer_chronique.html