Forum général.général lecteur de bande, cat et tailles de blocs

Posté par  .
Étiquettes : aucune
0
25
juil.
2005
Je possède un lecteur de bande scsi 2. La taille des blocs de ce lecteurs est laissé variable (mt setblk 0). La taille du tampon du pilote "st" est de 32768 B. J'ai écris sur une bande plusieurs fichiers à l'aide de simple "cat mon_fichier >/dev/nst0" et tous c'est bien passé.
Pour les lire, après avoir positionné la bande au bon endroit, je tape benoitemnt "cat /dev/nst0 >mon_fichier_récupéré" et là refus de mon bon Gnu/linux qui ne m'avais pourtant jamais déçu. Une histoire de blocs tros gros 32768 qui ne rentre pas dans les 4096 prévus et "st" qui ne peut pas allouer de mémoire etc.
Diable!
La commande cp produit le même effet
Bon!
Il semblerait que l'on ne puisse pas avoir accès aux blocs physiques de la bande dont la tailles de toutes façons restent inconnues et que le pilote "st" après avoir récupéré des données (je crois qu'il y a en plus une étape de décompression matérielle par le lecteur ) balance tout le contenu de son tampon d'un seul coup, soit 32768 B et qu'ensuite cat ou cp s'en plaignent, exigeant au plus des bouts de 4096B

Je tente alors un "dd if=/dev/nst0 of=mon_fichier_récupéré" et boum, même refus du système, 32768 qui ne rentre pas dans 512 ce coup ci ...
Ouf! "dd if=... of=... bs=32768" réussit et mes belles sauvegardes ne sont plus perdues.

J'en arrive à ma question. Si je veux utiliser la commande "cat", comment lui faire comprendre qu'elle accepte/demande des blocs indivisibles de 32768 en entrée ? (tar, elle possède une option --block-size, mais cat, cp non )

En fait par curiosité surtout : où/comment est fixée cette valeur implicite de 4096 Bytes de blocs de données max ? Par le système (pages? mais comment dd s'en tire t-il?) Lors de la compilation de cat ? Quelle est la nature de ces blocs ?

Une petite piste ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.