Bonjour à toutes et à tous :)
Voilà je galère un petit peu avec un lecteur SDLT, je cherche en effet à exploiter la compression matérielle pour arriver à faire des backup de près de 320 GB.
# cat /proc/scsi/scsi
Attached devices:
Host: scsi1 Channel: 00 Id: 06 Lun: 00
Vendor: COMPAQ Model: SDLT320 Rev: 2E2E
Type: Sequential-Access ANSI SCSI revision: 02
Mon OS est une redhat advanced server 2.1:
# uname -a
Linux titan 2.4.9-e.3smp #1 SMP Fri May 3 16:48:54 EDT 2002 i686 unknown
Pour activer la compression matérielle, j'utilise la commande suivante:
mt -f /dev/st0 compression
La commande donne comme code retour 0, ce qui laisse à penser (comme le dit le man) que la compression est belle et bien activée, on peut également le vérifier par cette autre commande:
# tapeinfo -f /dev/sg0
Product Type: Tape Drive
Vendor ID: 'COMPAQ '
Product ID: 'SDLT320 '
Revision: '2E2E'
Attached Changer: No
SerialNumber: 'PMC46Y1083 '
MinBlock:4
MaxBlock:16777212
SCSI ID: 6
SCSI LUN: 0
Ready: yes
BufferedMode: yes
Medium Type: 0x86
Density Code: 0x49
BlockSize: 0
DataCompEnabled: yes
DataCompCapable: yes
DataDeCompEnabled: yes
CompType: 0x10
DeCompType: 0x10
BOP: yes
Block Position: 0
Malgré ça, les backups ne dépassent pas les 160 GB, j'utilise la commande "dump" pour les réaliser.
Au passage, on peut détecter le code de densité du lecteur qui est 0x49.
Et c'est là où je crois avoir trouvé :
# mt -f /dev/st0 densities
Cette commande retourne une liste de code de densité relative aux différents type de lecteurs, et je constate que mon code de densité (0x49) n'y apparait pas :)
Alors j'ai décidé de regarder sur une autre redhat plus récente, et là, la commande "mt -f /dev/st0 densities" retourne une liste un peu plus complète que dans l'autre cas et je retrouve bien mon code de densité:
0x49 Quantum SDLT320
Malheureusement cette machine ne dispose pas d'un lecteur SDLT mais uniquement DLT et je ne peux pas tester en échangeant les lecteurs car ce sont des machines de prod, donc il me reste comme solution l'upgrade.
Au passage et pour conclure (ceux qui sont arrivés jusque ici sont courageux), les versions de paquets de mt-st sont les suivantes (pour les deux machines):
1°-- mt-st-0.7-6 (mon lecteur n'apparaît pas dans la liste des codes de densité)
2°-- mt-st-0.7-11 (mon lecteur est dans la liste des codes de densité)
Le seul soucis c'est que pour passer à la version 0.7-11 il faut que j'upgrade la libc donc que je mette à jour tout mon système :) bon bah faudra plannifier ça et prévenir les users :)
Bon si mon analyse de la situation est incomplète merci de m'en informer, et si vous avez réussi à exploiter la compression matérielle sur un SDLT merci de me transmettre votre mode opératoire :b
à bientôt
Forum Linux.redhat Lecteur SDLT COMPAQ (scsi-2)
15
avr.
2005
# test du soft ?
Posté par kolter (site web personnel, Mastodon) . Évalué à 4.
car je suppose que la dépendance n'en est pas vraiment une et qu'une compilation des sources doit le faire avec ta libc actuelle, voir même essayer de recompiler le src.rpm de mt-st-0.7-11 s'il existe !!
moi j'essaierais déjà ça histoire de ne faire l'upgrade qu'en dernier recours !
M.
[^] # Re: test du soft ?
Posté par Dabowl_94 . Évalué à 2.
dabowl_75
[^] # Re: test du soft ?
Posté par Dabowl_94 . Évalué à 2.
0x49 Quantum SDLT320
Mais après quelques réponses obtenues sur debian-user-french, il semblerait que les algorithmes mis en oeuvre dans les lecteurs sont équivalents à des gzip et que de ce fait on ne puisse pas obtenir le même gain de compression suivant le type de données, et dans mon cas il s'agit d'images (JPEG, TIFF etc...) et non de texte.
Donc il semblerait que je ne pourrais pas atteindre les 320 GB théoriques (pourtant écrit sur le papier :b), je pensais (à tort ?) que la compression matérielle permettait d'atteindre ce volume quelque soit les données que l'on sauvegarde.
si vous avez déjà réussi à atteindre ces 320 GB en sauvegardant des images...faîtes-moi signe :)
dabowl_75
[^] # Re: test du soft ?
Posté par fenril . Évalué à 1.
Je crains qu'il ne soit pas possible (et de loin) d'atteindre 320 GiB.
Si comme je le pense, ton lecteur est un 160/230 (160 non compressé), tu pourras AU MIEUX, sauvegarder 160GiB d'images.
Le taux de 320 est un argument commercial qui n'est atteint qu'avec des données fortement redondantes (textes, images non compressées avec beaucoup d'aplats de couleurs).
Avec des algorithmes de type Lempel-Ziv-Welch, ou Huffman, on obtient en general un résultat plus volumineux que l'original quand on veut compresser des données qui le sont déja. (mais dans ce cas le lecteur s'abstient.).
Il te reste les archives multi-volumes.
http://www.tandberg.com/superDLT/(...)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.