Aller au contenu

[RESOLU] Lecteur de bandes DAT12/24 SCSI


ggbce

Messages recommandés

Salut,

Suite à mon sujet précédent "Lecteur de bandes DAT SCSI avec Linux - Comment savoir quel dev ?" où j'ai réussi à trouver comment accéder à mon lecteur de bande et faire quelques tests d'écriture, j'aimerais avoir un petit coup de pouce pour le faire fonctionner correctement !

J'ai lu le man de mt, celui de st et celui de tar. J'ai compris qu'il est possible de paramétrer pas mal de chose en rapport au nombre de blocs, la grosseur de ceux-ci et faire des actions en rapport avec ioctl, mais dans la plupart des explications c'est mentionné que c'est jamais pareil et que ça peut ne pas fonctionner car il faut savoir si le lecteur supporte ou non ces fonctions :byebye:

C'est pas évident de savoir c'est quoi la taille des blocs à utiliser, est-ce un lecteur auto-rewind (st) ou non-rewind (nst), c'est quoi les options de mt supporté par mon lecteur,...

C'est pourquoi j'aimerais avoir de l'aide de vous.

Voici mon lecteur de bandes:

------------------------------------

Compaq/HP C1537A

DAT 12/24 Go, DDS-3, SCSI-2

------------------------------------

Quand je fais un mt -f /dev/st0 status j'obtiens:

SCSI 2 tape drive:
File number=0, block number=0, partition=0
Tape block size 0 bytes. Density code 0x25 (DDS-3).
Soft error count since last status=0
General status bits on (41010000):
BOT ONLINE IM_REP_EN

Si je fais un mt -f /dev/st0 erase, l'effacement de la bande fonctionne très bien.

Si je fais un mt -f /dev/st0 eject, l'éjection de la bande fonctionne très bien.

Mais mt -f /dev/st0 rewind ou mt -f /dev/st0 retension ne marche pas...

-------------------------

J'ai ensuite lancé une sauvegarde simple avec tar czvf /dev/st0 /testfolder qui a fonctionné sans problème !

J'ai donc essayé de récupérer les donées depuis le lecteur de bandes comme ceci cp /dev/st0 /restaure.tar, qui fonctionne bien avec mon lecteur de bande parallèle (c'est un autre tape que j'ai à la maison), et là j'ai bloqué !!!

Ça me donne le message:

st0: Failed to read 10240 byte block with 4096 byte read.
cp: reading '/dev/st0' : Ne peut allouer de la mémoire

Je dois comprendre que le nombre de blocs utilisés n'est pas valide ? Comment je fais pour bien configurer le tout, il n'existe pas vraiment de "standard" ?

Comme mt le spécifiait avec le status: Tape block size 0 bytes. Est-ce que c'est vraiment 0 ou c'est qu'il est géré automatique.

Là je suis perdu et je ne sais pas où trouver les infos pour bien configurer le tout. Je ne trouve rien depuis le site de Compaq/HP qui peut m'aider.

... j'oubliais, j'utilise des bandes: Maxell HS-4/125s DDS3 4mm 12/24 Go ou Sony DDS-3 DGD125P 12/24 Go. Si ça peut être nécessaire pour les paramètres.

-------------------

Mise à jour :

J'ai essayé de faire un tar tvf /dev/st0 au-lieu cp /dev/st0 /monarchive.tar afin de lire le contenu de la bande, et voici ce que j'ai comme résultat:

tar: This does not look like a tar archive
tar: Skipping to next header
tar: Archive contains obsolescent base-64 headers
tar: Archive contains '\027ÿvÍ\\»ýÛq'\022' whre numric off_t value expected
tar: Archive contains '\a\233ÿ>-:ë7' where numeric mode_t value expected
.... ainsi de suite avec les numric mode: time_t, uid_t et gid_t
tar: Skipping to next header

Et là le ruban contnie à dérouler !

Je ne sais pas si c'Est dû à un mauvais paramétrage, mauvaise façon de l'utiliser, une bande défectueuse, ...

Lien vers le commentaire
Partager sur d’autres sites

Oufff, là je comprends plus rien... mais ça commence à fonctionner :keskidit:

Tantôt j'ai essayé de reprendre les données du lecteur de bandes et restaurer le contenu comme ceci:

cp /dev/st0 /myarchive.tar

(* ce qui fonctionne avec mon lecteur HP 4Go parallèle).

Ça donnait cet erreur:

st0: Failed to read 10240 byte block with 4096 byte read.
cp: reading '/dev/st0' : Ne peut allouer de la mémoire

J'ai alors tenté la commande:

tar tvf /dev/st0

Pour connaître le contenu de l'archive sur la bande et ça m'a donné ça:

tar: This does not look like a tar archive
tar: Skipping to next header
tar: Archive contains obsolescent base-64 headers
tar: Archive contains '\027ÿvÍ\\»ýÛq'\022' whre numric off_t value expected
tar: Archive contains '\a\233ÿ>-:ë7' where numeric mode_t value expected
.... ainsi de suite avec les numric mode: time_t, uid_t et gid_t
tar: Skipping to next header

Finalement j'ai simplement essayé de restaurer le contenu de la bande avec:

tar xzvf /dev/st0

En me plaçant dans un dossier de réception temporaire (/test)... et l'extraction de l'archive se fait très bien !

------------------------------------------------------------------------

J'ai relu le manuel de tar et j'ai alors compris que tar utilise toujours des blocs de (N*512 octets) où N = 20 par défaut. Ce qui donne des blocs de 10240 octets.

Mais pourquoi si j'utilise cp pour récupérer le contenu il essai d'utiliser des blocs de 4096 octets ??? il n'est pas possible de spécifier la taille des blocs avec cp, est-ce le "par défaut" du système de travailler en bloc de 4096 ?

Si tar archive en bloc de 10240 octets et qu'il restaure en bloc de 10240 octets, pourquoi n'est-il pas capable de lister des fichiers en 10240 octets (tar tvf /dev/st0) ?

En tout cas j'ai une partie qui fonctionne, je peux maintenant m'intéresser à 2 autres points:

1- Devrais-je utiliser /dev/st0 ou /dev/nst0 ? pourquoi ?

2- Trouver un programme de gestion des archives utilisant tar en ligne de commande ? Amanda, Bacula, script manuel, Arkeia, ... ?

Lien vers le commentaire
Partager sur d’autres sites

De ce que je connais et de toutes les ressources que j'ai trouvé (bouquin et manuels d'aide), un lecteur de bande ne peut pas se monter comme un disque, c'est pas le même type d'accès. Il n'y a pas vraiment de table d'inodes ou de partition sur une bande magnétique.

Lien vers le commentaire
Partager sur d’autres sites

J'ai trouvé pourquoi le cp /dev/st0 /restaure.tar ne fonctionnait pas... c'est que le blocksize du lecteur SCSI est à 0 et c'est TAR qui gère la taille des blocs (512 octets par défaut) en accès sur le ruban, mais cp ne peut pas maitraiser la taille de bloc lors de l'accès à un périphérique.

Finalement c'est TAR qu'il faut vraiment utiliser (ou un autre programme fait pour accéder à des périphériques d'archivage comme dump).

Je commence à maîtriser bien la situation, je suis entrain de me faire un script qui analysera le mt status avec des validations et lancera ou non l'exécution de la sauvegarde, généra un rapport imprimé, ...

Reste à comprendre mieux TAR pour me permettre de créer plusieurs archives sur le même ruban avec les ID de position.

Lien vers le commentaire
Partager sur d’autres sites

Archivé

Ce sujet est désormais archivé et ne peut plus recevoir de nouvelles réponses.

×
×
  • Créer...