(Courriels de diversion: <oublierons@adjoignant-enrolaient.com> <musicographes@irriterent-jardinets.com> <inferieure@faciliterai-dialoguerions.com> <detelee@neigea-discerneras.com> <remorque@apitoye-eczema.com> <vaporises@craquerions-imaginerent.com> <infligiez@fluctuerai-retrace.com> <ondulait@taillait-attirerent.com> <equipez@homographe-reveillerez.com> <convoque@amputiez-zigzaguaient.com> )
'lut, >> > D'ailleurs dell déconseille tar à cause de la taille des blocks. >> >> Gni... Grumbl... Ourgl... >> >> La gestion du facteur de "blockage" reste quand meme le truc le plus >> marrant avec les bandes... du neuf pistes jusqu'au DLT et surtout entre >> archis et OS differents. J'ai du mal a concevoir le probleme de Dell >> sur le coup, à moins que ces #&@*$% (censure) se fassent faire des >> firmwares sauvages avec un facteur de "blockage" étrange (non >> multiple de 512o) uniquement montés sur les unités qu'ils vendent. > > Pas de doc là dessus. J'utilise le driver st sur une carte adaptec > 29160. Il n'y a pas de driver spécifiques sur le CD, juste «fonctionne > sous linux avec le driver de l'os». humpf... 29160 + driver carte linux + st en config de base : ca tourne ici. >> Usuellement, soit on se sert d'une pinouille en plastique pour >> basculer les DIP-switches sur l'unité elle meme, soit on utilise >> l'option suivante sur tar : -b, --block-size N block size of Nx512 >> bytes (default N=3D20). Tu pourras remarquer au passage que j'ai tendance >> à fuir les cpio'teries m'étant déjà fait pourrir la vie avec ça (pas de >> reglage du facteur de "blockage", juste du -B ou -C), et donc que je >> mon avis est assez partisan. > > ce que je reproche à tar, c'est qu'en cas de corruption, c'est quand > même plus dur à récupérer. Mais c'est juste un avis basé sur différentes > opinions lues à gauche à droite, sans réelle expérience. > Je vais continuer mes tests, jusqu'à trouver une solution... Regarde aussi tes cables (longueur, etat, contacts, proximité ligne 240V), ainsi que la presence d'un terminateur actif (et de preference externe à l'unité de bande). Ensuite ne resteront que le "blockage" des données, et l'inspection de la concurence DMA/IRQ sur ton bus PCI. Si tu as un pack de disques ou un raid hardware et une carte scsi pour les sauvegardes (config traditionnelle) essaye de mettre le raid-scsi sur le bus PCI primaire du serveur et la carte scsi de servitude (CDROM, DLT, tsoin-tsoin) sur le bus secondaire. M'enfin si ton serveur a deux bus. Derniere chose : verifie la numerotation de tes unités SCSI si tu as agloméré le tout sur un seul controleur. Les multiplexeurs LVD <---> SE, et WIDE <---> NARROW peuvent présenter des surprises (mappage du narrow sur le MSB ou LSB suivant les config materielles) et induire des effets de bord concernant la latence du systeme complet et le blocage du bus dans un mode pendant qu'une unité lente monopolise le bus en question. Ceci dit, ici, je n'ai _jamais_ entendu parler de perte de données sur un tar : l'entretien des lecteurs est fait de façon maniaque en préventif. (Meme les neufs pistes font l'objet d'un alignement de tete tous les mois). Les scripts sont "sécurisés" par controle des bandes après écriture, et surtout par création de plusieurs images identiques sur la même bande quand l'espace le permet : generalement 3 (la derniere est physiquement enterrée sous les tours de bandes autours des moyeux enroulés lors des deux premieres sauvegardes ). La production de données nouvelles n'est pas assez intense pour jouer à faire des sauvegardes intégrales et on a de quoi s'ébatre sur le support magnétique. Certaines données sont, elles, dupliquées sur un support quasi indestructible : le format QIC (150Mo par bande pour rester standardostandard selon une vielle orthodoxie unixienne). Bref, par ici, tar, mt, et parfois dump sont deux des mamelles du magnetisme appliqué. ;o) a+ ===[Ce message a ete lave par notre filtre anti-betises-airbus]== -------------------------------------------------------------------- Les listes de diffusion occultes: <URL:http://www.CULTe.org/listes/>