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
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' ?
C'est normal, ça veut dire que tu es en "soft block", donc c'est le logiciel qui écrit qui détermine la taille de bloc. Soit avec tar, 20 Ko.
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.
Ça devrait... les différences sont "dramatiques" avec les lecteurs que j'utilise en tout cas.
Tiens, anecdote marrante, comment cramer un lecteur LTO-4 ou LTO-5? en sauvegardant 20 To en blocs de 32 Ko, radical! J'ai un client qui a grillé 5 lecteurs comme ça... Le lecteur passe son temps à faire du "shoe shining" : il remplit son buffer (64 Mo ou un truc de ce genre), écrit pendant 0.5 secondes, puis se met en pause jusqu'à ce que le buffer soit rerempli, etc. Résultat la sauvegarde prend une semaine, pendant laquelle on calcule que le lecteur s'est mis en pause environ 300 000 fois. Pas étonnant que la mécanique en prenne un coup...
-- "Dope will get you through times of no money better than money will get you through times of no dope." Freewheelin' Franklin.
Le Tue, 31 May 2011 13:01:26 +0000, JKB a écrit:
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' ?
C'est normal, ça veut dire que tu es en "soft block", donc c'est le
logiciel qui écrit qui détermine la taille de bloc. Soit avec tar, 20 Ko.
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.
Ça devrait... les différences sont "dramatiques" avec les lecteurs que
j'utilise en tout cas.
Tiens, anecdote marrante, comment cramer un lecteur LTO-4 ou LTO-5? en
sauvegardant 20 To en blocs de 32 Ko, radical! J'ai un client qui a
grillé 5 lecteurs comme ça... Le lecteur passe son temps à faire du "shoe
shining" : il remplit son buffer (64 Mo ou un truc de ce genre), écrit
pendant 0.5 secondes, puis se met en pause jusqu'à ce que le buffer soit
rerempli, etc. Résultat la sauvegarde prend une semaine, pendant laquelle
on calcule que le lecteur s'est mis en pause environ 300 000 fois. Pas
étonnant que la mécanique en prenne un coup...
--
"Dope will get you through times of no money better
than money will get you through times of no dope."
Freewheelin' Franklin.
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' ?
C'est normal, ça veut dire que tu es en "soft block", donc c'est le logiciel qui écrit qui détermine la taille de bloc. Soit avec tar, 20 Ko.
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.
Ça devrait... les différences sont "dramatiques" avec les lecteurs que j'utilise en tout cas.
Tiens, anecdote marrante, comment cramer un lecteur LTO-4 ou LTO-5? en sauvegardant 20 To en blocs de 32 Ko, radical! J'ai un client qui a grillé 5 lecteurs comme ça... Le lecteur passe son temps à faire du "shoe shining" : il remplit son buffer (64 Mo ou un truc de ce genre), écrit pendant 0.5 secondes, puis se met en pause jusqu'à ce que le buffer soit rerempli, etc. Résultat la sauvegarde prend une semaine, pendant laquelle on calcule que le lecteur s'est mis en pause environ 300 000 fois. Pas étonnant que la mécanique en prenne un coup...
-- "Dope will get you through times of no money better than money will get you through times of no dope." Freewheelin' Franklin.
JKB
Le 31 May 2011 14:48:27 GMT, Emmanuel Florac écrivait :
Le Tue, 31 May 2011 13:01:26 +0000, JKB a écrit:
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' ?
C'est normal, ça veut dire que tu es en "soft block", donc c'est le logiciel qui écrit qui détermine la taille de bloc. Soit avec tar, 20 Ko.
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.
Ça devrait... les différences sont "dramatiques" avec les lecteurs que j'utilise en tout cas.
J'avoue ne pas avoir vu de différence sensible. Je vais donc essayer de faire une sauvegarde sans compression pour voir.
Tiens, anecdote marrante, comment cramer un lecteur LTO-4 ou LTO-5? en sauvegardant 20 To en blocs de 32 Ko, radical! J'ai un client qui a grillé 5 lecteurs comme ça... Le lecteur passe son temps à faire du "shoe shining" : il remplit son buffer (64 Mo ou un truc de ce genre), écrit pendant 0.5 secondes, puis se met en pause jusqu'à ce que le buffer soit rerempli, etc. Résultat la sauvegarde prend une semaine, pendant laquelle on calcule que le lecteur s'est mis en pause environ 300 000 fois. Pas étonnant que la mécanique en prenne un coup...
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
Le 31 May 2011 14:48:27 GMT,
Emmanuel Florac <eflorac@imaginet.fr> écrivait :
Le Tue, 31 May 2011 13:01:26 +0000, JKB a écrit:
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' ?
C'est normal, ça veut dire que tu es en "soft block", donc c'est le
logiciel qui écrit qui détermine la taille de bloc. Soit avec tar, 20 Ko.
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.
Ça devrait... les différences sont "dramatiques" avec les lecteurs que
j'utilise en tout cas.
J'avoue ne pas avoir vu de différence sensible. Je vais donc essayer
de faire une sauvegarde sans compression pour voir.
Tiens, anecdote marrante, comment cramer un lecteur LTO-4 ou LTO-5? en
sauvegardant 20 To en blocs de 32 Ko, radical! J'ai un client qui a
grillé 5 lecteurs comme ça... Le lecteur passe son temps à faire du "shoe
shining" : il remplit son buffer (64 Mo ou un truc de ce genre), écrit
pendant 0.5 secondes, puis se met en pause jusqu'à ce que le buffer soit
rerempli, etc. Résultat la sauvegarde prend une semaine, pendant laquelle
on calcule que le lecteur s'est mis en pause environ 300 000 fois. Pas
étonnant que la mécanique en prenne un coup...
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
Le 31 May 2011 14:48:27 GMT, Emmanuel Florac écrivait :
Le Tue, 31 May 2011 13:01:26 +0000, JKB a écrit:
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' ?
C'est normal, ça veut dire que tu es en "soft block", donc c'est le logiciel qui écrit qui détermine la taille de bloc. Soit avec tar, 20 Ko.
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.
Ça devrait... les différences sont "dramatiques" avec les lecteurs que j'utilise en tout cas.
J'avoue ne pas avoir vu de différence sensible. Je vais donc essayer de faire une sauvegarde sans compression pour voir.
Tiens, anecdote marrante, comment cramer un lecteur LTO-4 ou LTO-5? en sauvegardant 20 To en blocs de 32 Ko, radical! J'ai un client qui a grillé 5 lecteurs comme ça... Le lecteur passe son temps à faire du "shoe shining" : il remplit son buffer (64 Mo ou un truc de ce genre), écrit pendant 0.5 secondes, puis se met en pause jusqu'à ce que le buffer soit rerempli, etc. Résultat la sauvegarde prend une semaine, pendant laquelle on calcule que le lecteur s'est mis en pause environ 300 000 fois. Pas étonnant que la mécanique en prenne un coup...
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
JKB
Le Tue, 31 May 2011 15:10:41 +0000 (UTC), JKB écrivait :
Le 31 May 2011 14:48:27 GMT, Emmanuel Florac écrivait :
Le Tue, 31 May 2011 13:01:26 +0000, JKB a écrit:
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' ?
C'est normal, ça veut dire que tu es en "soft block", donc c'est le logiciel qui écrit qui détermine la taille de bloc. Soit avec tar, 20 Ko.
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.
Ça devrait... les différences sont "dramatiques" avec les lecteurs que j'utilise en tout cas.
J'avoue ne pas avoir vu de différence sensible. Je vais donc essayer de faire une sauvegarde sans compression pour voir.
Bon, chose amusante, si on veut. Lorsque je configure le lecteur pour qu'il n'utilise pas de compression et que je fais un bête tar cvf /dev/st0, le lecteur fonctionne pas à-coups comme s'il ne recevait pas assez vite les données. La carte sur laquelle est connectée le lecteur (avec un bouchon actif) possède son interruption propre.
Configuration de la machine (serveur SPARC avec deux UltraSPARC III+ à 900 MHz et 2 Go de mémoire) : - disques systèmes (raid1) sur du FCAL (52.96 MB/sec) [qla2xxx] - disques de données (raid6) sur du U320 (122.86 MB/sec) [ioc0] - un U320 disponible [ioc1] - un SCSI-UW disponible [sym53c8xx] - un SCSI-UW pour ce lecteur de bande et son robot associé [sym53c8xx]
Le lecteur est donné pour une vitesse maximale d'écriture de 10 Mo/s et il est reconnu comme :
sym1: <875> rev 0x37 at pci 0000:00:06.1 irq 17 sym1: No NVRAM, ID 7, Fast-20, SE, parity checking sym1: SCSI BUS has been reset. scsi2 : sym-2.2.3 scsi 2:0:6:0: Medium Changer ADIC Scalar DLT 448 0119 PQ: 0 ANSI: 2 scsi target2:0:6: Beginning Domain Validation scsi target2:0:6: Ending Domain Validation scsi 2:0:6:0: Attached scsi generic sg3 type 8 scsi 2:0:15:0: Sequential-Access QUANTUM DLT7000 2150 PQ: 0 ANSI: 2 scsi target2:0:15: Beginning Domain Validation scsi target2:0:15: FAST-10 WIDE SCSI 20.0 MB/s ST (100 ns, offset 15) scsi target2:0:15: Domain Validation skipping write tests scsi target2:0:15: Ending Domain Validation scsi 2:0:15:0: Attached scsi generic sg4 type 1
Il est entendu que cette machine ne fait rien d'autre lors des tests. Je n'arrive déjà pas à comprendre pourquoi les données n'arrivent pas assez vite. Je ne me souviens pas avoir eu ce genre de problème ni avec mon ancien DLT-4000, ni avec mon SLR-8. D'un autre côté, le débit d'information d'un DLT-4000 est plus proche des 3 à 5 Mo/s que des 10...
Si jamais tu avais une idée...
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
Le Tue, 31 May 2011 15:10:41 +0000 (UTC),
JKB <jkb@koenigsberg.invalid> écrivait :
Le 31 May 2011 14:48:27 GMT,
Emmanuel Florac <eflorac@imaginet.fr> écrivait :
Le Tue, 31 May 2011 13:01:26 +0000, JKB a écrit:
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' ?
C'est normal, ça veut dire que tu es en "soft block", donc c'est le
logiciel qui écrit qui détermine la taille de bloc. Soit avec tar, 20 Ko.
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.
Ça devrait... les différences sont "dramatiques" avec les lecteurs que
j'utilise en tout cas.
J'avoue ne pas avoir vu de différence sensible. Je vais donc essayer
de faire une sauvegarde sans compression pour voir.
Bon, chose amusante, si on veut. Lorsque je configure le lecteur
pour qu'il n'utilise pas de compression et que je fais un bête tar
cvf /dev/st0, le lecteur fonctionne pas à-coups comme s'il ne
recevait pas assez vite les données. La carte sur laquelle est
connectée le lecteur (avec un bouchon actif) possède son
interruption propre.
Configuration de la machine (serveur SPARC avec deux UltraSPARC III+
à 900 MHz et 2 Go de mémoire) :
- disques systèmes (raid1) sur du FCAL (52.96 MB/sec) [qla2xxx]
- disques de données (raid6) sur du U320 (122.86 MB/sec) [ioc0]
- un U320 disponible [ioc1]
- un SCSI-UW disponible [sym53c8xx]
- un SCSI-UW pour ce lecteur de bande et son robot associé [sym53c8xx]
Le lecteur est donné pour une vitesse maximale d'écriture de 10 Mo/s
et il est reconnu comme :
sym1: <875> rev 0x37 at pci 0000:00:06.1 irq 17
sym1: No NVRAM, ID 7, Fast-20, SE, parity checking
sym1: SCSI BUS has been reset.
scsi2 : sym-2.2.3
scsi 2:0:6:0: Medium Changer ADIC Scalar DLT 448 0119 PQ: 0 ANSI: 2
scsi target2:0:6: Beginning Domain Validation
scsi target2:0:6: Ending Domain Validation
scsi 2:0:6:0: Attached scsi generic sg3 type 8
scsi 2:0:15:0: Sequential-Access QUANTUM DLT7000 2150 PQ: 0 ANSI: 2
scsi target2:0:15: Beginning Domain Validation
scsi target2:0:15: FAST-10 WIDE SCSI 20.0 MB/s ST (100 ns, offset 15)
scsi target2:0:15: Domain Validation skipping write tests
scsi target2:0:15: Ending Domain Validation
scsi 2:0:15:0: Attached scsi generic sg4 type 1
Il est entendu que cette machine ne fait rien d'autre lors des
tests. Je n'arrive déjà pas à comprendre pourquoi les données
n'arrivent pas assez vite. Je ne me souviens pas avoir eu ce genre
de problème ni avec mon ancien DLT-4000, ni avec mon SLR-8. D'un
autre côté, le débit d'information d'un DLT-4000 est plus proche des
3 à 5 Mo/s que des 10...
Si jamais tu avais une idée...
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
Le Tue, 31 May 2011 15:10:41 +0000 (UTC), JKB écrivait :
Le 31 May 2011 14:48:27 GMT, Emmanuel Florac écrivait :
Le Tue, 31 May 2011 13:01:26 +0000, JKB a écrit:
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' ?
C'est normal, ça veut dire que tu es en "soft block", donc c'est le logiciel qui écrit qui détermine la taille de bloc. Soit avec tar, 20 Ko.
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.
Ça devrait... les différences sont "dramatiques" avec les lecteurs que j'utilise en tout cas.
J'avoue ne pas avoir vu de différence sensible. Je vais donc essayer de faire une sauvegarde sans compression pour voir.
Bon, chose amusante, si on veut. Lorsque je configure le lecteur pour qu'il n'utilise pas de compression et que je fais un bête tar cvf /dev/st0, le lecteur fonctionne pas à-coups comme s'il ne recevait pas assez vite les données. La carte sur laquelle est connectée le lecteur (avec un bouchon actif) possède son interruption propre.
Configuration de la machine (serveur SPARC avec deux UltraSPARC III+ à 900 MHz et 2 Go de mémoire) : - disques systèmes (raid1) sur du FCAL (52.96 MB/sec) [qla2xxx] - disques de données (raid6) sur du U320 (122.86 MB/sec) [ioc0] - un U320 disponible [ioc1] - un SCSI-UW disponible [sym53c8xx] - un SCSI-UW pour ce lecteur de bande et son robot associé [sym53c8xx]
Le lecteur est donné pour une vitesse maximale d'écriture de 10 Mo/s et il est reconnu comme :
sym1: <875> rev 0x37 at pci 0000:00:06.1 irq 17 sym1: No NVRAM, ID 7, Fast-20, SE, parity checking sym1: SCSI BUS has been reset. scsi2 : sym-2.2.3 scsi 2:0:6:0: Medium Changer ADIC Scalar DLT 448 0119 PQ: 0 ANSI: 2 scsi target2:0:6: Beginning Domain Validation scsi target2:0:6: Ending Domain Validation scsi 2:0:6:0: Attached scsi generic sg3 type 8 scsi 2:0:15:0: Sequential-Access QUANTUM DLT7000 2150 PQ: 0 ANSI: 2 scsi target2:0:15: Beginning Domain Validation scsi target2:0:15: FAST-10 WIDE SCSI 20.0 MB/s ST (100 ns, offset 15) scsi target2:0:15: Domain Validation skipping write tests scsi target2:0:15: Ending Domain Validation scsi 2:0:15:0: Attached scsi generic sg4 type 1
Il est entendu que cette machine ne fait rien d'autre lors des tests. Je n'arrive déjà pas à comprendre pourquoi les données n'arrivent pas assez vite. Je ne me souviens pas avoir eu ce genre de problème ni avec mon ancien DLT-4000, ni avec mon SLR-8. D'un autre côté, le débit d'information d'un DLT-4000 est plus proche des 3 à 5 Mo/s que des 10...
Si jamais tu avais une idée...
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
Emmanuel Florac
Le Tue, 31 May 2011 15:39:52 +0000, JKB a écrit:
Si jamais tu avais une idée...
Je ne vois pas trop, il me semble que les Sparc génération E450 à E10000 avaient des problèmes avec le PCI (interruptions et autres), mais cette machine est plus récente que ça? Au pire tu peux faire un
dd if=/dev/zero of=/dev/st1 bs8k
pour vérifier que les données arrivent au bon rythme... Sinon en désespoir de cause il y a peut-être un outil de diagnostic de lecteur spécialisé chez Quantum? Chez IBM et HP il y a (pour linux x86 seulement hélas).
-- L'Algérie était au bord du gouffre, aujourd'hui elle a fait un grand pas en avant. Kaid Ahmed.
Le Tue, 31 May 2011 15:39:52 +0000, JKB a écrit:
Si jamais tu avais une idée...
Je ne vois pas trop, il me semble que les Sparc génération E450 à E10000
avaient des problèmes avec le PCI (interruptions et autres), mais cette
machine est plus récente que ça? Au pire tu peux faire un
dd if=/dev/zero of=/dev/st1 bs8k
pour vérifier que les données arrivent au bon rythme...
Sinon en désespoir de cause il y a peut-être un outil de diagnostic de
lecteur spécialisé chez Quantum? Chez IBM et HP il y a (pour linux x86
seulement hélas).
--
L'Algérie était au bord du gouffre, aujourd'hui elle a fait un grand pas
en avant.
Kaid Ahmed.
Je ne vois pas trop, il me semble que les Sparc génération E450 à E10000 avaient des problèmes avec le PCI (interruptions et autres), mais cette machine est plus récente que ça? Au pire tu peux faire un
dd if=/dev/zero of=/dev/st1 bs8k
pour vérifier que les données arrivent au bon rythme... Sinon en désespoir de cause il y a peut-être un outil de diagnostic de lecteur spécialisé chez Quantum? Chez IBM et HP il y a (pour linux x86 seulement hélas).
-- L'Algérie était au bord du gouffre, aujourd'hui elle a fait un grand pas en avant. Kaid Ahmed.
JKB
Le 31 May 2011 20:42:25 GMT, Emmanuel Florac écrivait :
Le Tue, 31 May 2011 15:39:52 +0000, JKB a écrit:
Si jamais tu avais une idée...
Je ne vois pas trop, il me semble que les Sparc génération E450 à E10000 avaient des problèmes avec le PCI (interruptions et autres), mais cette machine est plus récente que ça? Au pire tu peux faire un
Oui, c'est une machine plus récente de deux générations. Et lorsque bacula tourne, les données arrivent bien en continu (en tout cas, largement mieux).
dd if=/dev/zero of=/dev/st1 bs8k
Je vais tester ça. L'idée initiale était de faire un tar sur une bande pour voir si la taille renvoyée par bacula était globalement la même que celle d'un tar de base. Avec dd, ça va être dur ;-) À moins de bricoler avec /dev/random, mais ça ne donnera rien sur la compression.
pour vérifier que les données arrivent au bon rythme... Sinon en désespoir de cause il y a peut-être un outil de diagnostic de lecteur spécialisé chez Quantum? Chez IBM et HP il y a (pour linux x86 seulement hélas).
À voir, donc...
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
Le 31 May 2011 20:42:25 GMT,
Emmanuel Florac <eflorac@imaginet.fr> écrivait :
Le Tue, 31 May 2011 15:39:52 +0000, JKB a écrit:
Si jamais tu avais une idée...
Je ne vois pas trop, il me semble que les Sparc génération E450 à E10000
avaient des problèmes avec le PCI (interruptions et autres), mais cette
machine est plus récente que ça? Au pire tu peux faire un
Oui, c'est une machine plus récente de deux générations. Et lorsque
bacula tourne, les données arrivent bien en continu (en tout cas,
largement mieux).
dd if=/dev/zero of=/dev/st1 bs8k
Je vais tester ça. L'idée initiale était de faire un tar sur une
bande pour voir si la taille renvoyée par bacula était globalement
la même que celle d'un tar de base. Avec dd, ça va être dur ;-) À
moins de bricoler avec /dev/random, mais ça ne donnera rien sur la
compression.
pour vérifier que les données arrivent au bon rythme...
Sinon en désespoir de cause il y a peut-être un outil de diagnostic de
lecteur spécialisé chez Quantum? Chez IBM et HP il y a (pour linux x86
seulement hélas).
À voir, donc...
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
Le 31 May 2011 20:42:25 GMT, Emmanuel Florac écrivait :
Le Tue, 31 May 2011 15:39:52 +0000, JKB a écrit:
Si jamais tu avais une idée...
Je ne vois pas trop, il me semble que les Sparc génération E450 à E10000 avaient des problèmes avec le PCI (interruptions et autres), mais cette machine est plus récente que ça? Au pire tu peux faire un
Oui, c'est une machine plus récente de deux générations. Et lorsque bacula tourne, les données arrivent bien en continu (en tout cas, largement mieux).
dd if=/dev/zero of=/dev/st1 bs8k
Je vais tester ça. L'idée initiale était de faire un tar sur une bande pour voir si la taille renvoyée par bacula était globalement la même que celle d'un tar de base. Avec dd, ça va être dur ;-) À moins de bricoler avec /dev/random, mais ça ne donnera rien sur la compression.
pour vérifier que les données arrivent au bon rythme... Sinon en désespoir de cause il y a peut-être un outil de diagnostic de lecteur spécialisé chez Quantum? Chez IBM et HP il y a (pour linux x86 seulement hélas).
À voir, donc...
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
Emmanuel Florac
Le Wed, 01 Jun 2011 06:59:31 +0000, JKB a écrit:
Je ne vois pas trop, il me semble que les Sparc génération E450 à E10000 avaient des problèmes avec le PCI (interruptions et autres), mais cette machine est plus récente que ça? Au pire tu peux faire un
Oui, c'est une machine plus récente de deux générations. Et lorsque bacula tourne, les données arrivent bien en continu (en tout cas, largement mieux).
C'est bizarre, ça. Si bacula y arrive, pourquoi pas tar?
-- "If you're not paying for it, you're not the customer; you are the product being sold."
Le Wed, 01 Jun 2011 06:59:31 +0000, JKB a écrit:
Je ne vois pas trop, il me semble que les Sparc génération E450 à
E10000 avaient des problèmes avec le PCI (interruptions et autres),
mais cette machine est plus récente que ça? Au pire tu peux faire un
Oui, c'est une machine plus récente de deux générations. Et lorsque
bacula tourne, les données arrivent bien en continu (en tout cas,
largement mieux).
C'est bizarre, ça. Si bacula y arrive, pourquoi pas tar?
--
"If you're not paying for it, you're not the customer; you are
the product being sold."
Je ne vois pas trop, il me semble que les Sparc génération E450 à E10000 avaient des problèmes avec le PCI (interruptions et autres), mais cette machine est plus récente que ça? Au pire tu peux faire un
Oui, c'est une machine plus récente de deux générations. Et lorsque bacula tourne, les données arrivent bien en continu (en tout cas, largement mieux).
C'est bizarre, ça. Si bacula y arrive, pourquoi pas tar?
-- "If you're not paying for it, you're not the customer; you are the product being sold."
JKB
Le 01 Jun 2011 07:08:01 GMT, Emmanuel Florac écrivait :
Le Wed, 01 Jun 2011 06:59:31 +0000, JKB a écrit:
Je ne vois pas trop, il me semble que les Sparc génération E450 à E10000 avaient des problèmes avec le PCI (interruptions et autres), mais cette machine est plus récente que ça? Au pire tu peux faire un
Oui, c'est une machine plus récente de deux générations. Et lorsque bacula tourne, les données arrivent bien en continu (en tout cas, largement mieux).
C'est bizarre, ça. Si bacula y arrive, pourquoi pas tar?
C'est une excellente question que je me pose depuis hier soir. Maintenant, de toi à moi, je trouve parfaitement débile de la part du constructeur de ne pas avoir collé comme interface un SCSI-UW pour ne pas avoir plus de 25% de la bande passante occupée par le lecteur. J'ai la chance de pouvoir isoler ce lecteur sur une carte, mais ce n'est pas toujours le cas... Je vais me pencher sur le problème de bande passante dès que j'ai un moment à moi. En fait, je n'arrive pas à identifier le goulot d'étranglement.
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
Le 01 Jun 2011 07:08:01 GMT,
Emmanuel Florac <eflorac@imaginet.fr> écrivait :
Le Wed, 01 Jun 2011 06:59:31 +0000, JKB a écrit:
Je ne vois pas trop, il me semble que les Sparc génération E450 à
E10000 avaient des problèmes avec le PCI (interruptions et autres),
mais cette machine est plus récente que ça? Au pire tu peux faire un
Oui, c'est une machine plus récente de deux générations. Et lorsque
bacula tourne, les données arrivent bien en continu (en tout cas,
largement mieux).
C'est bizarre, ça. Si bacula y arrive, pourquoi pas tar?
C'est une excellente question que je me pose depuis hier soir.
Maintenant, de toi à moi, je trouve parfaitement débile de la part
du constructeur de ne pas avoir collé comme interface un SCSI-UW
pour ne pas avoir plus de 25% de la bande passante occupée par le
lecteur. J'ai la chance de pouvoir isoler ce lecteur sur une carte,
mais ce n'est pas toujours le cas... Je vais me pencher sur le
problème de bande passante dès que j'ai un moment à moi. En fait, je
n'arrive pas à identifier le goulot d'étranglement.
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
Le 01 Jun 2011 07:08:01 GMT, Emmanuel Florac écrivait :
Le Wed, 01 Jun 2011 06:59:31 +0000, JKB a écrit:
Je ne vois pas trop, il me semble que les Sparc génération E450 à E10000 avaient des problèmes avec le PCI (interruptions et autres), mais cette machine est plus récente que ça? Au pire tu peux faire un
Oui, c'est une machine plus récente de deux générations. Et lorsque bacula tourne, les données arrivent bien en continu (en tout cas, largement mieux).
C'est bizarre, ça. Si bacula y arrive, pourquoi pas tar?
C'est une excellente question que je me pose depuis hier soir. Maintenant, de toi à moi, je trouve parfaitement débile de la part du constructeur de ne pas avoir collé comme interface un SCSI-UW pour ne pas avoir plus de 25% de la bande passante occupée par le lecteur. J'ai la chance de pouvoir isoler ce lecteur sur une carte, mais ce n'est pas toujours le cas... Je vais me pencher sur le problème de bande passante dès que j'ai un moment à moi. En fait, je n'arrive pas à identifier le goulot d'étranglement.
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
Emmanuel Florac
Le Wed, 01 Jun 2011 07:22:31 +0000, JKB a écrit:
Je vais me pencher sur le problème de bande passante dès que j'ai un moment à moi. En fait, je n'arrive pas à identifier le goulot d'étranglement.
Bon, au pire si tu n'y arrives pas tu peux faire un saut à Suresnes avec ton bouzin, j'ai de quoi le brancher pour tester :)
-- When the people fears the government, there is tyranny; when the government fears the people, there is liberty. Thomas Jefferson.
Le Wed, 01 Jun 2011 07:22:31 +0000, JKB a écrit:
Je vais me pencher sur le problème de bande passante
dès que j'ai un moment à moi. En fait, je n'arrive pas à
identifier le goulot d'étranglement.
Bon, au pire si tu n'y arrives pas tu peux faire un saut à Suresnes avec
ton bouzin, j'ai de quoi le brancher pour tester :)
--
When the people fears the government, there is tyranny; when the
government fears the people, there is liberty.
Thomas Jefferson.
