j'ai des soucis avec un lecteur de bande;
J'utilise amanda pour faire des sauvegardes, le changeur de bandes
est un dell powervault 122T.
La distrib est une debian sarge, noyau 2.6.8.
Jusque là tout marchait plutôt bien, depuis quelques jours j'ai des
erreurs.
Je lance la commande amflush pour sauvegarder les fichiers du disque
vers la bande, il commence à écrire les fichiers, et au bout d'un moment
il me remonte une erreur.
j'ai ces messages lorsque je lance amflush avec les options -f -s
--------------------------------------------------------------
driver: state time 138.721 free kps: 9000 space: 2320912 taper: writing
idle-dumpers: 4 qlen tapeq: 13 runq: 0 roomq: 0 wakeup: 86400
driver-idle: not-idle
driver: interface-state time 138.721 if : free 9000
driver: hdisk-state time 138.721 hdisk 0: free 2320912 dumpers 0
taper: writing end marker. [4 ERR kb 2194656 fm 4]
--------------------------------------------------------------
ou auparavant, lorsque je le lançais en arriere plan, je recevais
en message:
--------------------------------------------------------------
These dumps were to tape 1.
*** A TAPE ERROR OCCURRED: [[writing file: Input/output error]].
Some dumps may have been left in the holding disk.
Run amflush to flush them to tape.
The next tape Amanda expects to use is: 3.
--------------------------------------------------------------
dans le /var/log/messages j'ai ça:
--------------------------------------------------------------
Mar 6 17:47:55 servsauvegarde kernel: st0: Error with sense data:
Deferred st0: sense key Medium Error
Mar 6 17:47:55 servsauvegarde kernel: Additional sense: Write error
--------------------------------------------------------------
Je vois aussi ce message d'erreur:
--------------------------------------------------------------
st0: Block limits 1 - 16777215 bytes.
--------------------------------------------------------------
Des recherches sur google ne m'ont pas aidé à trouver des solutions,
(j'ai vu des problèmes similaires mais rien qui m'aide beaucoup),
est ce que quelqu'un saurait comment je peux me dépatouiller?
Vu le côté aléatoire du problème je subodore un problème matériel mais
je voudrais être sûr avant de changer le lecteur de bande (c'est pas
donné ces bestioles).
ps:
J'ai passé deux fois une cassette nettoyante, ça ne semble pas résoudre
le problème... J'ai également changé une des bandes, ça n'a pas changé
gand chose non plus.
Surtout, pense bien qu'il est impératif d'alimenter le lecteur suffisamment vite : si tu alimentes un lecteur en dessous de sa vitesse maximale, il remplit son cache, écrit sur la bande, se met en pause, remplit son cache, écrit sur la bande, se met en pause... ça use très rapidement la mécanique.
Le fameux "shoe shine".
Curieusement, sur deux configurations que je connais (une librairie STK avec 6 DLT7000 et une librairie avec 4 LTO1) c'est plus des problèmes de cables et/ou de terminateurs qu'on voyait alors que, gros backups sur réseau tout pourri, on aurait pu s'attendre à l'inverse.
Sur la librairie STK notamment, le premier mois avait été infernal, des erreurs tous les jours, on a changé bandes et lecteurs plusieurs fois, sans effet. Les controleurs SCSI du serveur aussi, autant pisser dans un violon. Puis STK a changé tous les cables internes et du jour au lendemain, nickel !
Puis pendant des mois et des mois, no problemo, même avec des compteurs de start/stop qui atteignaient des niveaux hallucinants.
Mais dès qu'on touchait un peu pas gentiment à un cable, les erreurs aléatoires se repointaient.
Sinon, pour aider l'OP, si le changement de lecteur n'améliore pas la situation, il peut essayer de se reporter à la sagesse des Anciens (Google SCSI black goat).
-- You're a ha-a-a-ard man, McGee!
Emmanuel Florac <eflorac@imaginet.fr> writes:
Surtout, pense bien qu'il est impératif d'alimenter le lecteur
suffisamment vite : si tu alimentes un lecteur en dessous de sa vitesse
maximale, il remplit son cache, écrit sur la bande, se met en pause,
remplit son cache, écrit sur la bande, se met en pause... ça use
très rapidement la mécanique.
Le fameux "shoe shine".
Curieusement, sur deux configurations que je connais (une librairie
STK avec 6 DLT7000 et une librairie avec 4 LTO1) c'est plus des
problèmes de cables et/ou de terminateurs qu'on voyait alors que, gros
backups sur réseau tout pourri, on aurait pu s'attendre à l'inverse.
Sur la librairie STK notamment, le premier mois avait été infernal,
des erreurs tous les jours, on a changé bandes et lecteurs plusieurs
fois, sans effet. Les controleurs SCSI du serveur aussi, autant
pisser dans un violon. Puis STK a changé tous les cables internes et
du jour au lendemain, nickel !
Puis pendant des mois et des mois, no problemo, même avec des
compteurs de start/stop qui atteignaient des niveaux hallucinants.
Mais dès qu'on touchait un peu pas gentiment à un cable, les erreurs
aléatoires se repointaient.
Sinon, pour aider l'OP, si le changement de lecteur n'améliore pas la
situation, il peut essayer de se reporter à la sagesse des Anciens
(Google SCSI black goat).
Surtout, pense bien qu'il est impératif d'alimenter le lecteur suffisamment vite : si tu alimentes un lecteur en dessous de sa vitesse maximale, il remplit son cache, écrit sur la bande, se met en pause, remplit son cache, écrit sur la bande, se met en pause... ça use très rapidement la mécanique.
Le fameux "shoe shine".
Curieusement, sur deux configurations que je connais (une librairie STK avec 6 DLT7000 et une librairie avec 4 LTO1) c'est plus des problèmes de cables et/ou de terminateurs qu'on voyait alors que, gros backups sur réseau tout pourri, on aurait pu s'attendre à l'inverse.
Sur la librairie STK notamment, le premier mois avait été infernal, des erreurs tous les jours, on a changé bandes et lecteurs plusieurs fois, sans effet. Les controleurs SCSI du serveur aussi, autant pisser dans un violon. Puis STK a changé tous les cables internes et du jour au lendemain, nickel !
Puis pendant des mois et des mois, no problemo, même avec des compteurs de start/stop qui atteignaient des niveaux hallucinants.
Mais dès qu'on touchait un peu pas gentiment à un cable, les erreurs aléatoires se repointaient.
Sinon, pour aider l'OP, si le changement de lecteur n'améliore pas la situation, il peut essayer de se reporter à la sagesse des Anciens (Google SCSI black goat).
-- You're a ha-a-a-ard man, McGee!
Emmanuel Florac
Le Thu, 08 Mar 2007 11:02:30 +0100, Throckmorton P. Gildersleeve a écrit :
Mais dès qu'on touchait un peu pas gentiment à un cable, les erreurs aléatoires se repointaient.
Je peux confirmer que j'ai eu des problèmes infinis de câbles SCSI, en particulier avec le SCSI parallèle de dernière génération : SCSI 320... En 160 un peu moins (pas mal quand même), en Ultra2 et Ultra assez aussi.
-- A thing of beauty is a joy forever. J. Keats.
Ah! Singe débotté, hisse un jouet fort et vert! Marcel Bénabou.
Le Thu, 08 Mar 2007 11:02:30 +0100, Throckmorton P. Gildersleeve a
écrit :
Mais dès qu'on touchait un peu pas gentiment à un cable, les erreurs
aléatoires se repointaient.
Je peux confirmer que j'ai eu des problèmes infinis de câbles SCSI, en
particulier avec le SCSI parallèle de dernière génération : SCSI
320... En 160 un peu moins (pas mal quand même), en Ultra2 et Ultra assez
aussi.
--
A thing of beauty is a joy forever.
J. Keats.
Ah! Singe débotté, hisse un jouet fort et vert!
Marcel Bénabou.
Le Thu, 08 Mar 2007 11:02:30 +0100, Throckmorton P. Gildersleeve a écrit :
Mais dès qu'on touchait un peu pas gentiment à un cable, les erreurs aléatoires se repointaient.
Je peux confirmer que j'ai eu des problèmes infinis de câbles SCSI, en particulier avec le SCSI parallèle de dernière génération : SCSI 320... En 160 un peu moins (pas mal quand même), en Ultra2 et Ultra assez aussi.
-- A thing of beauty is a joy forever. J. Keats.
Ah! Singe débotté, hisse un jouet fort et vert! Marcel Bénabou.
Tanguy
Non, mais si tu sauvegardes directement depuis les disques, il faut que ceux ci alimentent le lecteur usffisamment vite (regarde les specs de ton lecteur et teste la performance de tes disques). C'est nettement plus critique si tu sauvegardes à travers le réseau : en 100Bt, tu ne peux pas dépasser 8 ou 10 Mo/s, donc il ne faut surtout pas utiliser un lecteur dont la vitesse nominale est 30 Mo/s, ça le démolirait à coup sûr.
bonjour,
* bon avec un lecteur tout neuf ça fonctionne de nouveau :) La commande dmesg me donne toujours : st0: Block limits 1 - 16777215 bytes. (je ne comprends pas trop ce message... )
* sinon par rapport à l'histoire de débit, dans le fichier amanda.conf j'ai ça: netusage 9000
et inparallel 4
et les specs du lecteur annoncent 15 Mo/s, ou 30Mo/s en mode compressé, (mais ça je pense que c'est un peu pipeau, non? faut considérer 15Mo/s, je pense)
* le "holding disk" a 12Go de libres.
Si j'ai bien compris, amanda va tenter de lancer 4 sauvegardes en parallèle, et utiliser le "holding disk" si le lecteur est occupé à écrire sur bande... donc ma config n'est pas bonne, puisque le lecteur écrira plus vite sur la bande que ce que fournira le reseau (9Mo/s)... comment puis je changer ça?
* pour info j'ai lancé bonnie++ (je connaissais pas) pour tester les perfs du disque dur, je trouve ça:
:~$ bonnie++ -d /data Writing with putc()...done Writing intelligently...done Rewriting...done Reading with getc()...done Reading intelligently...done start 'em...done...done...done... Create files in sequential order...done. Stat files in sequential order...done. Delete files in sequential order...done. Create files in random order...done. Stat files in random order...done. Delete files in random order...done. Version 1.03 ------Sequential Output------ --Sequential Input- --Random- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP servsauvegarde 1G 19436 95 30433 22 13317 8 19411 88 47270 11 519.9 1 ------Sequential Create------ --------Random Create-------- -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 1604 98 +++++ +++ +++++ +++ 1649 98 +++++ +++ 6848 100 servsauvegarde,1G,19436,95,30433,22,13317,8,19411,88,47270,11,519.9,1,16,1604,98,+++++,+++,+++++,+++,1649,98,+++++,+++,6848,100
Non, mais si tu sauvegardes directement depuis les disques, il faut que
ceux ci alimentent le lecteur usffisamment vite (regarde les specs de ton
lecteur et teste la performance de tes disques).
C'est nettement plus critique si tu sauvegardes à travers le réseau : en
100Bt, tu ne peux pas dépasser 8 ou 10 Mo/s, donc il ne faut surtout pas
utiliser un lecteur dont la vitesse nominale est 30 Mo/s, ça le
démolirait à coup sûr.
bonjour,
* bon avec un lecteur tout neuf ça fonctionne de nouveau :)
La commande dmesg me donne toujours :
st0: Block limits 1 - 16777215 bytes.
(je ne comprends pas trop ce message... )
* sinon par rapport à l'histoire de débit, dans le fichier amanda.conf
j'ai ça:
netusage 9000
et
inparallel 4
et les specs du lecteur annoncent 15 Mo/s, ou 30Mo/s en mode compressé,
(mais ça je pense que c'est un peu pipeau, non? faut considérer 15Mo/s,
je pense)
* le "holding disk" a 12Go de libres.
Si j'ai bien compris, amanda va tenter de lancer 4 sauvegardes en
parallèle, et utiliser le "holding disk" si le lecteur est occupé à
écrire sur bande... donc ma config n'est pas bonne, puisque le lecteur
écrira plus vite sur la bande que ce que fournira le reseau (9Mo/s)...
comment puis je changer ça?
* pour info j'ai lancé bonnie++ (je connaissais pas) pour tester les
perfs du disque dur, je trouve ça:
backup@servsauvegarde:~$ bonnie++ -d /data
Writing with putc()...done
Writing intelligently...done
Rewriting...done
Reading with getc()...done
Reading intelligently...done
start 'em...done...done...done...
Create files in sequential order...done.
Stat files in sequential order...done.
Delete files in sequential order...done.
Create files in random order...done.
Stat files in random order...done.
Delete files in random order...done.
Version 1.03 ------Sequential Output------ --Sequential Input-
--Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block--
--Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP
/sec %CP
servsauvegarde 1G 19436 95 30433 22 13317 8 19411 88 47270 11
519.9 1
------Sequential Create------ --------Random
Create--------
-Create-- --Read--- -Delete-- -Create-- --Read---
-Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
/sec %CP
16 1604 98 +++++ +++ +++++ +++ 1649 98 +++++ +++
6848 100
servsauvegarde,1G,19436,95,30433,22,13317,8,19411,88,47270,11,519.9,1,16,1604,98,+++++,+++,+++++,+++,1649,98,+++++,+++,6848,100
Non, mais si tu sauvegardes directement depuis les disques, il faut que ceux ci alimentent le lecteur usffisamment vite (regarde les specs de ton lecteur et teste la performance de tes disques). C'est nettement plus critique si tu sauvegardes à travers le réseau : en 100Bt, tu ne peux pas dépasser 8 ou 10 Mo/s, donc il ne faut surtout pas utiliser un lecteur dont la vitesse nominale est 30 Mo/s, ça le démolirait à coup sûr.
bonjour,
* bon avec un lecteur tout neuf ça fonctionne de nouveau :) La commande dmesg me donne toujours : st0: Block limits 1 - 16777215 bytes. (je ne comprends pas trop ce message... )
* sinon par rapport à l'histoire de débit, dans le fichier amanda.conf j'ai ça: netusage 9000
et inparallel 4
et les specs du lecteur annoncent 15 Mo/s, ou 30Mo/s en mode compressé, (mais ça je pense que c'est un peu pipeau, non? faut considérer 15Mo/s, je pense)
* le "holding disk" a 12Go de libres.
Si j'ai bien compris, amanda va tenter de lancer 4 sauvegardes en parallèle, et utiliser le "holding disk" si le lecteur est occupé à écrire sur bande... donc ma config n'est pas bonne, puisque le lecteur écrira plus vite sur la bande que ce que fournira le reseau (9Mo/s)... comment puis je changer ça?
* pour info j'ai lancé bonnie++ (je connaissais pas) pour tester les perfs du disque dur, je trouve ça:
:~$ bonnie++ -d /data Writing with putc()...done Writing intelligently...done Rewriting...done Reading with getc()...done Reading intelligently...done start 'em...done...done...done... Create files in sequential order...done. Stat files in sequential order...done. Delete files in sequential order...done. Create files in random order...done. Stat files in random order...done. Delete files in random order...done. Version 1.03 ------Sequential Output------ --Sequential Input- --Random- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP servsauvegarde 1G 19436 95 30433 22 13317 8 19411 88 47270 11 519.9 1 ------Sequential Create------ --------Random Create-------- -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 1604 98 +++++ +++ +++++ +++ 1649 98 +++++ +++ 6848 100 servsauvegarde,1G,19436,95,30433,22,13317,8,19411,88,47270,11,519.9,1,16,1604,98,+++++,+++,+++++,+++,1649,98,+++++,+++,6848,100
Emmanuel Florac
Le Fri, 09 Mar 2007 09:14:43 +0100, Tanguy a écrit :
Si j'ai bien compris, amanda va tenter de lancer 4 sauvegardes en parallèle, et utiliser le "holding disk" si le lecteur est occupé à écrire sur bande... donc ma config n'est pas bonne, puisque le lecteur écrira plus vite sur la bande que ce que fournira le reseau (9Mo/s)... comment puis je changer ça?
* pour info j'ai lancé bonnie++ (je connaissais pas) pour tester les perfs du disque dur, je trouve ça:
Ton disque est assez rapide (tout juste...) pour fournir ton lecteur. Je ne sais pas paramétrer Amanda, mais il faudrait que tu sauvegardes vers le holding disk au maximum avant de commencer à écrire sur la bande, de façon à avoir le débit (c'est à dire en fait faire d'abord la sauvegarde sur disque, puis vers la fin commencer à transférer sur bande). Et surtout, désactive la compression. Ça gagne en perf et en place, mais en cas de souci de bande tu perds toute une sauvegarde au lieu d'un fichier!
Au cas où tu peux lancer une sauvegarde normale, et écouter attentivement le lecteur pendant : si tu l'entends se mettre en pause (clic clic) régulièrement, il faut vraiment passer par le disque intermérdiaire (sinon tu vas encore bousiller le lecteur).
-- A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. Robert A. Heinlein.
Le Fri, 09 Mar 2007 09:14:43 +0100, Tanguy a écrit :
Si j'ai bien compris, amanda va tenter de lancer 4 sauvegardes en
parallèle, et utiliser le "holding disk" si le lecteur est occupé à
écrire sur bande... donc ma config n'est pas bonne, puisque le lecteur
écrira plus vite sur la bande que ce que fournira le reseau (9Mo/s)...
comment puis je changer ça?
* pour info j'ai lancé bonnie++ (je connaissais pas) pour tester les
perfs du disque dur, je trouve ça:
Ton disque est assez rapide (tout juste...) pour fournir ton lecteur. Je
ne sais pas paramétrer Amanda, mais il faudrait que tu sauvegardes vers
le holding disk au maximum avant de commencer à écrire sur la bande, de
façon à avoir le débit (c'est à dire en fait faire d'abord la
sauvegarde sur disque, puis vers la fin commencer à transférer sur
bande). Et surtout, désactive la compression. Ça gagne en perf et en
place, mais en cas de souci de bande tu perds toute une sauvegarde au lieu
d'un fichier!
Au cas où tu peux lancer une sauvegarde normale, et écouter
attentivement le lecteur pendant : si tu l'entends se mettre en pause
(clic clic) régulièrement, il faut vraiment passer par le disque
intermérdiaire (sinon tu vas encore bousiller le lecteur).
--
A human being should be able to change a diaper, plan an invasion,
butcher a hog, conn a ship, design a building, write a sonnet, balance
accounts, build a wall, set a bone, comfort the dying, take orders, give
orders, cooperate, act alone, solve equations, analyze a new problem,
pitch manure, program a computer, cook a tasty meal, fight efficiently,
die gallantly. Specialization is for insects.
Robert A. Heinlein.
Le Fri, 09 Mar 2007 09:14:43 +0100, Tanguy a écrit :
Si j'ai bien compris, amanda va tenter de lancer 4 sauvegardes en parallèle, et utiliser le "holding disk" si le lecteur est occupé à écrire sur bande... donc ma config n'est pas bonne, puisque le lecteur écrira plus vite sur la bande que ce que fournira le reseau (9Mo/s)... comment puis je changer ça?
* pour info j'ai lancé bonnie++ (je connaissais pas) pour tester les perfs du disque dur, je trouve ça:
Ton disque est assez rapide (tout juste...) pour fournir ton lecteur. Je ne sais pas paramétrer Amanda, mais il faudrait que tu sauvegardes vers le holding disk au maximum avant de commencer à écrire sur la bande, de façon à avoir le débit (c'est à dire en fait faire d'abord la sauvegarde sur disque, puis vers la fin commencer à transférer sur bande). Et surtout, désactive la compression. Ça gagne en perf et en place, mais en cas de souci de bande tu perds toute une sauvegarde au lieu d'un fichier!
Au cas où tu peux lancer une sauvegarde normale, et écouter attentivement le lecteur pendant : si tu l'entends se mettre en pause (clic clic) régulièrement, il faut vraiment passer par le disque intermérdiaire (sinon tu vas encore bousiller le lecteur).
-- A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. Robert A. Heinlein.
Tanguy
Ton disque est assez rapide (tout juste...) pour fournir ton lecteur. Je ne sais pas paramétrer Amanda, mais il faudrait que tu sauvegardes vers le holding disk au maximum avant de commencer à écrire sur la bande, de façon à avoir le débit (c'est à dire en fait faire d'abord la sauvegarde sur disque, puis vers la fin commencer à transférer sur bande).
oui c'est ça qu'il faudrait faire. j'ai trouvé un lien intéressant ici: http://www.mail-archive.com//msg36877.html (je le mets là, ça pourrait servir à quelqu'un qui rencontrerait le même problème)
dans les mails de rapport d'amanda je vois ça: -------------------------------------------------------- Total Full Daily -------- -------- -------- Estimate Time (hrs:min) 0:02 Run Time (hrs:min) 4:28 Dump Time (hrs:min) 7:30 6:28 1:02 Output Size (meg) 42663.9 39608.2 3055.7 Original Size (meg) 79175.3 74415.3 4760.0 Avg Compressed Size (%) 53.9 53.2 64.2 (level:#disks ...) Filesystems Dumped 89 31 58 (1:57 2:1) Avg Dump Rate (k/s) 1619.2 1741.5 847.5
donc écriture moyenne de 11Mo/s, je dois bien avoir du "shoe-shining" sur le lecteur
Et surtout, désactive la compression. Ça gagne en perf et en place, mais en cas de souci de bande tu perds toute une sauvegarde au lieu d'un fichier!
ok. ça c'est facile à faire, je vais faire ça.
Au cas où tu peux lancer une sauvegarde normale, et écouter attentivement le lecteur pendant : si tu l'entends se mettre en pause (clic clic) régulièrement, il faut vraiment passer par le disque intermérdiaire (sinon tu vas encore bousiller le lecteur).
je vais me pencher sérieusement là dessus aujourd'hui... note: Je reprends amanda sur le tas, je ne connais pas très bien non plus...
ps: ...en fait mon message était assez HS sur ce newsgroup, désolé, au passage on y apprend des trucs quand même ;)
Ton disque est assez rapide (tout juste...) pour fournir ton lecteur. Je
ne sais pas paramétrer Amanda, mais il faudrait que tu sauvegardes vers
le holding disk au maximum avant de commencer à écrire sur la bande, de
façon à avoir le débit (c'est à dire en fait faire d'abord la
sauvegarde sur disque, puis vers la fin commencer à transférer sur
bande).
oui c'est ça qu'il faudrait faire.
j'ai trouvé un lien intéressant ici:
http://www.mail-archive.com/amanda-users@amanda.org/msg36877.html
(je le mets là, ça pourrait servir à quelqu'un qui rencontrerait le même
problème)
dans les mails de rapport d'amanda je vois ça:
--------------------------------------------------------
Total Full Daily
-------- -------- --------
Estimate Time (hrs:min) 0:02
Run Time (hrs:min) 4:28
Dump Time (hrs:min) 7:30 6:28 1:02
Output Size (meg) 42663.9 39608.2 3055.7
Original Size (meg) 79175.3 74415.3 4760.0
Avg Compressed Size (%) 53.9 53.2 64.2 (level:#disks ...)
Filesystems Dumped 89 31 58 (1:57 2:1)
Avg Dump Rate (k/s) 1619.2 1741.5 847.5
donc écriture moyenne de 11Mo/s, je dois bien avoir du "shoe-shining"
sur le lecteur
Et surtout, désactive la compression. Ça gagne en perf et en
place, mais en cas de souci de bande tu perds toute une sauvegarde au lieu
d'un fichier!
ok. ça c'est facile à faire, je vais faire ça.
Au cas où tu peux lancer une sauvegarde normale, et écouter
attentivement le lecteur pendant : si tu l'entends se mettre en pause
(clic clic) régulièrement, il faut vraiment passer par le disque
intermérdiaire (sinon tu vas encore bousiller le lecteur).
je vais me pencher sérieusement là dessus aujourd'hui...
note: Je reprends amanda sur le tas, je ne connais pas très bien non
plus...
ps: ...en fait mon message était assez HS sur ce newsgroup, désolé, au
passage on y apprend des trucs quand même ;)
Ton disque est assez rapide (tout juste...) pour fournir ton lecteur. Je ne sais pas paramétrer Amanda, mais il faudrait que tu sauvegardes vers le holding disk au maximum avant de commencer à écrire sur la bande, de façon à avoir le débit (c'est à dire en fait faire d'abord la sauvegarde sur disque, puis vers la fin commencer à transférer sur bande).
oui c'est ça qu'il faudrait faire. j'ai trouvé un lien intéressant ici: http://www.mail-archive.com//msg36877.html (je le mets là, ça pourrait servir à quelqu'un qui rencontrerait le même problème)
dans les mails de rapport d'amanda je vois ça: -------------------------------------------------------- Total Full Daily -------- -------- -------- Estimate Time (hrs:min) 0:02 Run Time (hrs:min) 4:28 Dump Time (hrs:min) 7:30 6:28 1:02 Output Size (meg) 42663.9 39608.2 3055.7 Original Size (meg) 79175.3 74415.3 4760.0 Avg Compressed Size (%) 53.9 53.2 64.2 (level:#disks ...) Filesystems Dumped 89 31 58 (1:57 2:1) Avg Dump Rate (k/s) 1619.2 1741.5 847.5
donc écriture moyenne de 11Mo/s, je dois bien avoir du "shoe-shining" sur le lecteur
Et surtout, désactive la compression. Ça gagne en perf et en place, mais en cas de souci de bande tu perds toute une sauvegarde au lieu d'un fichier!
ok. ça c'est facile à faire, je vais faire ça.
Au cas où tu peux lancer une sauvegarde normale, et écouter attentivement le lecteur pendant : si tu l'entends se mettre en pause (clic clic) régulièrement, il faut vraiment passer par le disque intermérdiaire (sinon tu vas encore bousiller le lecteur).
je vais me pencher sérieusement là dessus aujourd'hui... note: Je reprends amanda sur le tas, je ne connais pas très bien non plus...
ps: ...en fait mon message était assez HS sur ce newsgroup, désolé, au passage on y apprend des trucs quand même ;)
Thierry Boudet
On 2007-03-09, Emmanuel Florac wrote:
Au cas où tu peux lancer une sauvegarde normale, et écouter attentivement le lecteur pendant : si tu l'entends se mettre en pause (clic clic) régulièrement, il faut vraiment passer par le disque intermérdiaire (sinon tu vas encore bousiller le lecteur).
Tu penses donc qu'un DAT qui "clapote" parce que les paquets
de données arrivent trop lentement du réseau est en danger de destruction massive ? Existe-il des remèdes à ça, genre para- -métrage du driver, bufferisation pas un dd intermédiaire ?...
--
Une fois que les rudiments de la programmation sont maitrisés je pense que de passer sur un langage plus puissant style Basic est a envisager. Celle-là mériterait une entrée dans fortune...
--{ il suffit de demander... }--
On 2007-03-09, Emmanuel Florac <eflorac@imaginet.fr> wrote:
Au cas où tu peux lancer une sauvegarde normale, et écouter
attentivement le lecteur pendant : si tu l'entends se mettre en pause
(clic clic) régulièrement, il faut vraiment passer par le disque
intermérdiaire (sinon tu vas encore bousiller le lecteur).
Tu penses donc qu'un DAT qui "clapote" parce que les paquets
de données arrivent trop lentement du réseau est en danger de
destruction massive ? Existe-il des remèdes à ça, genre para-
-métrage du driver, bufferisation pas un dd intermédiaire ?...
--
Une fois que les rudiments de la programmation sont maitrisés je pense que
de passer sur un langage plus puissant style Basic est a envisager.
Celle-là mériterait une entrée dans fortune...
Au cas où tu peux lancer une sauvegarde normale, et écouter attentivement le lecteur pendant : si tu l'entends se mettre en pause (clic clic) régulièrement, il faut vraiment passer par le disque intermérdiaire (sinon tu vas encore bousiller le lecteur).
Tu penses donc qu'un DAT qui "clapote" parce que les paquets
de données arrivent trop lentement du réseau est en danger de destruction massive ? Existe-il des remèdes à ça, genre para- -métrage du driver, bufferisation pas un dd intermédiaire ?...
--
Une fois que les rudiments de la programmation sont maitrisés je pense que de passer sur un langage plus puissant style Basic est a envisager. Celle-là mériterait une entrée dans fortune...
--{ il suffit de demander... }--
Emmanuel Florac
Le Sat, 10 Mar 2007 07:49:59 +0000, Thierry Boudet a écrit :
Tu penses donc qu'un DAT qui "clapote" parce que les paquets de données arrivent trop lentement du réseau est en danger de destruction massive ?
C'est même certain. Les supports les plus sensibles sont le DAT (une vraie merde de toute façon) et le DLT (rupture fréquente de l'accroche de bande).
Existe-il des remèdes à ça, genre para- -métrage du driver, bufferisation pas un dd intermédiaire ?...
Bufferiser sur un DD intermédiaire, ou plutôt un RAID est une bonne idée... Il faut se méfier, les lecteurs actuels sont fantastiquement rapides (LTO-3 60Mo/s au moins) et il faut les nourrir!
-- on passe la moitié de son temps à refaire ce que l'on n'a pas eu le temps de faire correctement. Loi de Myers.
Le Sat, 10 Mar 2007 07:49:59 +0000, Thierry Boudet a écrit :
Tu penses donc qu'un DAT qui "clapote" parce que les paquets
de données arrivent trop lentement du réseau est en danger de
destruction massive ?
C'est même certain. Les supports les plus sensibles sont le DAT (une
vraie merde de toute façon) et le DLT (rupture fréquente de l'accroche
de bande).
Existe-il des remèdes à ça, genre para-
-métrage du driver, bufferisation pas un dd intermédiaire ?...
Bufferiser sur un DD intermédiaire, ou plutôt un RAID est une bonne
idée... Il faut se méfier, les lecteurs actuels sont fantastiquement
rapides (LTO-3 60Mo/s au moins) et il faut les nourrir!
--
on passe la moitié de son temps à refaire ce que l'on n'a pas eu le
temps de faire correctement.
Loi de Myers.
Le Sat, 10 Mar 2007 07:49:59 +0000, Thierry Boudet a écrit :
Tu penses donc qu'un DAT qui "clapote" parce que les paquets de données arrivent trop lentement du réseau est en danger de destruction massive ?
C'est même certain. Les supports les plus sensibles sont le DAT (une vraie merde de toute façon) et le DLT (rupture fréquente de l'accroche de bande).
Existe-il des remèdes à ça, genre para- -métrage du driver, bufferisation pas un dd intermédiaire ?...
Bufferiser sur un DD intermédiaire, ou plutôt un RAID est une bonne idée... Il faut se méfier, les lecteurs actuels sont fantastiquement rapides (LTO-3 60Mo/s au moins) et il faut les nourrir!
-- on passe la moitié de son temps à refaire ce que l'on n'a pas eu le temps de faire correctement. Loi de Myers.
Le Gaulois
Bufferiser sur un DD intermédiaire, ou plutôt un RAID est une bonne idée... Il faut se méfier, les lecteurs actuels sont fantastiquement rapides (LTO-3 60Mo/s au moins) et il faut les nourrir!
Avec un Tandberg SLR24 : 2h15 pour sauvegarder 12,5 Go. Il n'y a pas besoin de se méfier de sa fantastique rapidité (ça fait du 1,6 Mo/s) :-(
Bufferiser sur un DD intermédiaire, ou plutôt un RAID est une bonne
idée... Il faut se méfier, les lecteurs actuels sont fantastiquement
rapides (LTO-3 60Mo/s au moins) et il faut les nourrir!
Avec un Tandberg SLR24 : 2h15 pour sauvegarder 12,5 Go. Il n'y a pas
besoin de se méfier de sa fantastique rapidité (ça fait du 1,6 Mo/s)
:-(
Bufferiser sur un DD intermédiaire, ou plutôt un RAID est une bonne idée... Il faut se méfier, les lecteurs actuels sont fantastiquement rapides (LTO-3 60Mo/s au moins) et il faut les nourrir!
Avec un Tandberg SLR24 : 2h15 pour sauvegarder 12,5 Go. Il n'y a pas besoin de se méfier de sa fantastique rapidité (ça fait du 1,6 Mo/s) :-(
Emmanuel Florac
Le Sat, 10 Mar 2007 22:30:02 +0100, Le Gaulois a écrit :
Avec un Tandberg SLR24 : 2h15 pour sauvegarder 12,5 Go. Il n'y a pas besoin de se méfier de sa fantastique rapidité (ça fait du 1,6 Mo/s) :-(
Le SLR est assez lent (il convient bien du coup aux sauvegardes sur réseau, comme le VXA pour la même raison), cependant 1.6 Mo/s c'est nettement moins qu'attendu. Tu devrais benchmarker ton lecteur et tes disques, ce n'est peut-être pas normal.
-- Sutor ne ultra Crepidam.
Le Sat, 10 Mar 2007 22:30:02 +0100, Le Gaulois a écrit :
Avec un Tandberg SLR24 : 2h15 pour sauvegarder 12,5 Go. Il n'y a pas
besoin de se méfier de sa fantastique rapidité (ça fait du 1,6 Mo/s)
:-(
Le SLR est assez lent (il convient bien du coup aux sauvegardes sur
réseau, comme le VXA pour la même raison), cependant 1.6 Mo/s c'est
nettement moins qu'attendu. Tu devrais benchmarker ton lecteur et tes
disques, ce n'est peut-être pas normal.
Le Sat, 10 Mar 2007 22:30:02 +0100, Le Gaulois a écrit :
Avec un Tandberg SLR24 : 2h15 pour sauvegarder 12,5 Go. Il n'y a pas besoin de se méfier de sa fantastique rapidité (ça fait du 1,6 Mo/s) :-(
Le SLR est assez lent (il convient bien du coup aux sauvegardes sur réseau, comme le VXA pour la même raison), cependant 1.6 Mo/s c'est nettement moins qu'attendu. Tu devrais benchmarker ton lecteur et tes disques, ce n'est peut-être pas normal.
