Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Matériel Ordinateur Stockage Capacité de bandes DLT-7000

Capacité de bandes DLT-7000

18 réponses
Avatar
JKB
Bonjour à tous,

Je viens d'installer un antique FastStor-7000 sur un serveur et je
pilote la chose par Bacula. Je n'ai pas de problème de
configuration, seule une histoire de capacité me pose problème.

La configuration est la suivante :
- six bandes 35/70 Go ;
- une bande de nettoyage (activée automatiquement par la
bibliothèque) ;
- configuration matérielle forcée en 35C (bande de 35 Go compressée) ;
- pas de compression par bacula.

Après une première sauvegarde complète, les logs de bacula me
donnent :

- backup-1 empty
- backup-2 empty
- backup-3 full 35,93 GiB
- backup-4 full 43,52 GiB
- backup-5 full 30,96 GiB
- backup-6 append 11,80 GiB

et là, quelque chose m'échappe. Si j'ai bien tout compris, je
devrais pouvoir mettre sur une bande compressée de 35 Go plus de 35
Go (je n'espère pas atteindre les 70 Go). Les données sauvegardées
sont principalement des fichiers texte donc qui se compressent
aisément.

D'où la question suivante : pourquoi backup-5 fait-il moins de 35 Go ?
Il est entendu que la bande est bien une bande de 35 Go non
compressée. J'ai presque envie de poser la même question pour
backup-3 (dumps de tables SQL _ASCII_). J'ai l'impression que j'ai
raté un truc, mais je ne vois pas quoi...

Cordialement,

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2
Avatar
Emmanuel Florac
Le Thu, 05 May 2011 07:55:21 +0000, JKB a écrit:

- configuration matérielle forcée en 35C (bande de 35 Go compressée) ;
- pas de compression par bacula.



La première chose qui me vient à l'idée c'est que la compression n'est
pas réellement active :) Que donne un "mt status" sur le lecteur -
attention, avec le mt de mt-st, pas le mt bancal de cpio ?

--
L'esprit qu'on veut avoir gâte celui qu'on a.
Jean-Baptiste Louis Grisset.
Avatar
Emmanuel Florac
Le Sat, 28 May 2011 15:56:49 +0000, Emmanuel Florac a écrit:


La première chose qui me vient à l'idée c'est que la compression n'est
pas réellement active Que donne un "mt status" sur le lecteur -
attention, avec le mt de mt-st, pas le mt bancal de cpio ?



Je viens de vérifier, le "density code" pour des DLT 35 Go doit être 0x84
si la compression n'est PAS active, et 0x85 si elle l'est.

--
a script is what you give the actors, a program is what you give the
audience.
Ada Lovelace according to Larry Wall
Avatar
JKB
Le 28 May 2011 15:56:49 GMT,
Emmanuel Florac écrivait :
Le Thu, 05 May 2011 07:55:21 +0000, JKB a écrit:

- configuration matérielle forcée en 35C (bande de 35 Go compressée) ;
- pas de compression par bacula.



La première chose qui me vient à l'idée c'est que la compression n'est
pas réellement active :) Que donne un "mt status" sur le lecteur -
attention, avec le mt de mt-st, pas le mt bancal de cpio ?



Lorsqu'une bande est chargée, le lecteur mouline et affiche
fièrement DC, signe que la compression est activée.

Root rayleigh:[/dev] > mt-st -f /dev/nst0 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 0 bytes. Density code 0x1b (DLT 35GB).
Soft error count since last status=0
General status bits on (41010000):
BOT ONLINE IM_REP_EN
Root rayleigh:[/dev] >

Je viens donc de lui forcer la densité comme ceci :

Root rayleigh:[/dev] > mt-st -f /dev/nst0 setdensity 0x85

On va voir ce que ça donne...

Cordialement,

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Avatar
JKB
Le 28 May 2011 16:18:08 GMT,
Emmanuel Florac écrivait :
Le Sat, 28 May 2011 15:56:49 +0000, Emmanuel Florac a écrit:


La première chose qui me vient à l'idée c'est que la compression n'est
pas réellement active Que donne un "mt status" sur le lecteur -
attention, avec le mt de mt-st, pas le mt bancal de cpio ?



Je viens de vérifier, le "density code" pour des DLT 35 Go doit être 0x84
si la compression n'est PAS active, et 0x85 si elle l'est.



Et le 1b, à quoi correspond-il ?

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Avatar
Emmanuel Florac
Le Sat, 28 May 2011 18:59:33 +0000, JKB a écrit:

Et le 1b, à quoi correspond-il ?




Si j'en crois le tableau que j'ai manuellement compilé moi-même depuis un
grand nombre de sources (et un certain nombre de lecteurs de bandes :)
C'est aussi du "DLT 35GB", mais sans considération pour la compression
(??).

Tiens voici le tableau complet à toutes fins utiles :

code description
0x00 default
0x01 NRZI (800 bpi)
0x02 PE (1600 bpi)
0x03 GCR (6250 bpi)
0x04 QIC-11
0x05 QIC-45/60 (GCR, 8000 bpi)
0x06 PE (3200 bpi)
0x07 IMFM (6400 bpi)
0x08 GCR (8000 bpi)
0x09 GCR (37871 bpi)
0x0a MFM (6667 bpi)
0x0b PE (1600 bpi)
0x0c GCR (12960 bpi)
0x0d GCR (25380 bpi)
0x0f QIC-120 (GCR 10000 bpi)
0x10 QIC-150/250 (GCR 10000 bpi)
0x11 QIC-320/525 (GCR 16000 bpi)
0x12 QIC-1350 (RLL 51667 bpi)
0x13 DDS (61000 bpi)
0x14 EXB-8200 (RLL 43245 bpi)
0x15 EXB-8500 or QIC-1000
0x16 MFM 10000 bpi
0x17 MFM 42500 bpi
0x18 TZ86
0x19 DLT 10GB
0x1a DLT 20GB
0x1b DLT 35GB
0x1c QIC-385M
0x1d QIC-410M
0x1e QIC-1000C
0x1f QIC-2100C
0x20 QIC-6GB
0x21 QIC-20GB
0x22 QIC-2GB
0x23 QIC-875
0x24 DDS-2
0x25 DDS-3
0x26 DDS-4 or QIC-4GB
0x27 Exabyte Mammoth
0x28 Exabyte Mammoth-2
0x29 QIC-3080MC
0x30 AIT-1 or MLR3
0x31 AIT-2
0x32 AIT-3 / SLR7
0x33 SLR6
0x34 SLR100
0x40 DLT1 40 GB, or Ultrium
0x41 DLT 40GB, or Ultrium2
0x42 LTO-2
0x44 LTO-3
0x45 QIC-3095-MC (TR-4)
0x46 LTO-4
0x47 TR-5 / DDS-5
0x48 Quantum SDLT220
0x49 Quantum SDLT320
0x51 IBM 3592 J1A
0x52 IBM 3592 E05
0x58 LTO-5
0x80 DLT 15GB uncomp. or Ecrix / VXA-1
0x81 DLT 15GB compressed / VXA-2
0x82 DLT 20GB uncompressed / VXA-3 / VXA-320
0x83 DLT 20GB compressed
0x84 DLT 35GB uncompressed
0x85 DLT 35GB compressed
0x86 DLT1 40 GB uncompressed
0x87 DLT1 40 GB compressed
0x88 DLT 40GB uncompressed
0x89 DLT 40GB compressed
0x8c EXB-8505 compressed
0x90 SDLT110 uncompr/EXB-8205 compr
0x91 SDLT110 compressed
0x92 SDLT160 uncompressed
0x93 SDLT160 compressed


--
I have not failed. I've just found 10,000 ways that won't work.
Thomas A. Edison
Avatar
JKB
Le 28 May 2011 19:58:19 GMT,
Emmanuel Florac écrivait :
Le Sat, 28 May 2011 18:59:33 +0000, JKB a écrit:

Et le 1b, à quoi correspond-il ?




Si j'en crois le tableau que j'ai manuellement compilé moi-même depuis un
grand nombre de sources (et un certain nombre de lecteurs de bandes :)
C'est aussi du "DLT 35GB", mais sans considération pour la compression
(??).



Merci.

Je viens de relancer un backup complet et j'obtiens :

Build OS: sparc-unknown-linux-gnu debian wheezy/sid
JobId: 1
Job: Rayleigh.2011-05-28_21.25.17_05
Backup Level: Full
Client: "rayleigh-fd" 5.0.3 (04Aug10)
sparc-unknown-linux-gnu,debian,wheezy/sid
FileSet: "Full Set" 2011-05-03 11:48:40
Pool: "Default" (From Job resource)
Catalog: "MyCatalog" (From Client resource)
Storage: "FastStor-7000" (From command line)
Scheduled time: 28-May-2011 21:25:11
Start time: 28-May-2011 21:25:19
End time: 29-May-2011 12:38:19
Elapsed time: 15 hours 13 mins
Priority: 10
FD Files Written: 496,430
SD Files Written: 496,430
FD Bytes Written: 124,589,474,253 (124.5 GB)
SD Bytes Written: 124,672,996,860 (124.6 GB)
Rate: 2274.4 KB/s
Software Compression: None
VSS: no
Encryption: no
Accurate: no
Volume name(s): Backup-1|Backup-4|Backup-3|Backup-5
Volume Session Id: 1
Volume Session Time: 1306609188
Last Volume Bytes: 10,183,090,176 (10.18 GB)
Non-fatal FD errors: 0
SD Errors: 0
FD termination status: OK
SD termination status: OK
Termination: Backup OK

Jusque-là, tout semble bon.

Problème, la console bacula me renvoie :

*list volumes
Pool: Default
+---------+------------+-----------+---------+-------------+----------+--------------+---------+------+-----------+-----------+---------------------+
| MediaId | VolumeName | VolStatus | Enabled | VolBytes | VolFiles |
VolRetention | Recycle | Slot | InChanger | MediaType | LastWritten
|
+---------+------------+-----------+---------+-------------+----------+--------------+---------+------+-----------+-----------+---------------------+
| 1 | Backup-1 | Full | 1 | 44615273472 | 45 |
5184000 | 1 | 1 | 1 | DLT-7000 | 2011-05-29
01:32:23 |
| 2 | Backup-3 | Full | 1 | 32399668224 | 33 |
5184000 | 1 | 3 | 1 | DLT-7000 | 2011-05-29
11:45:14 |
| 3 | Backup-4 | Full | 1 | 37584110592 | 38 |
5184000 | 1 | 4 | 1 | DLT-7000 | 2011-05-29
09:44:34 |
| 4 | Backup-5 | Append | 1 | 10291018752 | 12 |
5184000 | 1 | 5 | 1 | DLT-7000 | 2011-05-29
12:40:24 |
| 5 | Backup-6 | Recycle | 1 | 12376369152 | 13 |
5184000 | 1 | 6 | 1 | DLT-7000 | 2011-05-04
03:16:58 |
| 6 | Backup-2 | Recycle | 1 | 2999808000 | 3 |
5184000 | 1 | 2 | 1 | DLT-7000 | 2011-05-07
23:22:31 |
+---------+------------+-----------+---------+-------------+----------+--------------+---------+------+-----------+-----------+---------------------+
Pool: File
No results to list.
Pool: Scratch
No results to list.
Pool: Differential
No results to list.
*

Désolé, ça dépasse un peu des 80 colonnes. La question reste donc
toujours la même. La première bande (1) fait un peu plus de 42 Go.
La deuxième (4) en fait un peu plus de 35. La troisième (3) un peu
moins de 31 et la dernière (5), un peu moins de 10.

Les données sont principalement du texte. Je conçois donc mal la
taille des données écrites sur les trois dernières bandes.
Naturellement, ces trois bandes sont toute des DLT-35/70.

Cordialement,

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Avatar
Emmanuel Florac
Le Sun, 29 May 2011 17:05:56 +0000, JKB a écrit:

Les données sont principalement du texte. Je conçois donc mal la taille
des données écrites sur les trois dernières bandes. Naturellement, ces
trois bandes sont toute des DLT-35/70.



C'est très mystérieux en effet. Je n'ai aucun lecteur vaguement
comparable, mais les LTO ont une compression extrèmement efficace, on
gagne même avec des fichiers compressés.

Si tu as une cassette vierge sous le coude, essaie de la remplir avec un
bête tar sans compression (mais compression active sur le lecteur) pour
voir si Bacula ne fait pas des blagues.

--
For every complex problem there is an answer that is clear, simple,
and wrong.
H. L. Mencken
Avatar
JKB
Le 29 May 2011 17:16:34 GMT,
Emmanuel Florac écrivait :
Le Sun, 29 May 2011 17:05:56 +0000, JKB a écrit:

Les données sont principalement du texte. Je conçois donc mal la taille
des données écrites sur les trois dernières bandes. Naturellement, ces
trois bandes sont toute des DLT-35/70.



C'est très mystérieux en effet. Je n'ai aucun lecteur vaguement
comparable, mais les LTO ont une compression extrèmement efficace, on
gagne même avec des fichiers compressés.

Si tu as une cassette vierge sous le coude, essaie de la remplir avec un
bête tar sans compression (mais compression active sur le lecteur) pour
voir si Bacula ne fait pas des blagues.



Bon, j'ai réussi à écrire directement sur une cartouche (pas bien
dur en même temps...). Sauf qu'à la lecture, je me suis pris un
superbe :

Message from at May 30 23:45:18 ...
kernel:Kernel panic - not syncing: Aiee, killing interrupt handler!

Message from at May 30 23:45:18 ...
kernel:Press Stop-A (L1-A) to return to the boot prom

Message from at May 30 23:47:19 ...
kernel:Kernel panic - not syncing: Aiee, killing interrupt handler!

Message from at May 30 23:47:19 ...
kernel:Press Stop-A (L1-A) to return to the boot prom

Encore une merde linuxienne d'un noyau codé par des pieds... Le
linux/sparc, c'est vraiment devenu n'importe quoi !... Je sais, j'ai
quatre cartes SCSI dans ma blade 2000, mais ce n'est _pas_ une
raison. Si Linux devient aussi mauvais que Solaris, où va-t-on ?
Ce qui est assez amusant, c'est que le stop+A ne fonctionne jamais
dans ce cas...

Ce qui me semble aussi bizarre, c'est que le lecteur n'écrit ni ne lit en
continu, comme si la puissance du circuit effectuant la compression
et la décompression n'était pas assez rapide. Je n'ai jamais observé
un tel comportement avec mon DLT-4000 de la même origine (mais sans
robot). La lecture par un tar xvf /dev/st0 est vraiment très lente
(plus en tout cas que celle de mon lecteur SLR-8 au cul de ma SS20
ou que celle de mon DLT-4000 au cul de la même blade). J'ai même
l'impression que la lecture est plus lente que l'écriture. Avec
Bacula, j'ai un taux de transfert conforme à ce que donnent les
specs du lecteur (sauf que durant plusieurs minutes, bacula peut
faire les pieds au mur, mais c'est un autre problème).

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Avatar
Emmanuel Florac
Le Tue, 31 May 2011 07:23:07 +0000, JKB a écrit:

Ce qui me semble aussi bizarre, c'est que le lecteur n'écrit ni ne lit
en continu, comme si la puissance du circuit effectuant la compression
et la décompression n'était pas assez rapide.



Ah crotte, ça peut être parce que tar utilise des blocs de 20 Ko par
défaut. Il faut vérifier que la taille de bloc de tar est adaptée à celle
paramétrée sur le lecteur, ou l'augmenter si le lecteur a un blocking
factor à 0. Normalement avec 128 Ko par bloc la perf doit être suffisante.

--
There are only two kinds of languages: the ones people complain about
and the ones nobody uses.
Bjarne Stroustrup
Avatar
JKB
Le 31 May 2011 10:19:29 GMT,
Emmanuel Florac écrivait :
Le Tue, 31 May 2011 07:23:07 +0000, JKB a écrit:

Ce qui me semble aussi bizarre, c'est que le lecteur n'écrit ni ne lit
en continu, comme si la puissance du circuit effectuant la compression
et la décompression n'était pas assez rapide.



Ah crotte, ça peut être parce que tar utilise des blocs de 20 Ko par
défaut. Il faut vérifier que la taille de bloc de tar est adaptée à celle
paramétrée sur le lecteur, ou l'augmenter si le lecteur a un blocking
factor à 0. Normalement avec 128 Ko par bloc la perf doit être suffisante.



Je viens d'essayer un certain nombre d'options sans succès. La
sortie de mt m'étonne :

Root rayleigh:[/usr/src/linux-2.6.39] > mt-st -f /dev/st0 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 0 bytes. Density code 0x1b (DLT 35GB).
Soft error count since last status=0
General status bits on (41010000):
BOT ONLINE IM_REP_EN

Pourquoi ai-je 'Tape block size 0 bytes' ?

Parallèlement, je suis en train d'essayer un
tar cvf -b 256 /dev/st0 . histoire de voir si le changement de la
taille des blocs influe.

Cordialement,

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
1 2