<<< DISK$DATA:[NOTES$LIBRARY]VAX_HARDWARE.NOTE;1 >>> -< VAX hardware >- ================================================================================ Note 216.0 RD53 tres malade 8 replies DECUSF::LEGUEVA_A "Alex Leguevaques FOCEPY Auxerre" 10 lines 31-JUL-1991 10:10 -------------------------------------------------------------------------------- Ayant des erreurs a repetition sur un RD53 (qui va etre remplace sous peu pour cette raison),je voudrais savoir s'il est possible de déterminer,d'apres l'errorlog,quels sont les (eventuels) fichiers malades. Sinon,quels sont les moyens de verif,a part ANAL/DISK,qui ne raconte rien(mais ne me rassure pas pour autant),et ANAL/RMS,qui n'est valable (obviously) que pour les fichiers... ...RMS ? Je pensais a un BACKUP/VERIFY,ai-je tort ? Merci d'avance pour toute info. A.L. ================================================================================ Note 216.1 RD53 tres malade 1 of 8 DECUSF::BERENGUIER_A "Alain, ALCATEL BUSINESS SYSTEM" 7 lines 31-JUL-1991 10:46 -< Non-RMS ??? >- -------------------------------------------------------------------------------- ???? A moins de monter le disque "/foreign", et d'avoir son propre gestionnaire de fichier, en ne travaillant qu'avec des QIO, et en formatant le disque de maniere toute a fait particuliere, je ne vois pas comment vous pouvez avoir des fichiers "autres que RMS". Si vous utilisez Backup, votre disque est monter file11, donc RMS ( ODS1 ou ODS2 ), et par la meme ANAL /RMS devrait marcher. ================================================================================ Note 216.2 RD53 tres malade 2 of 8 DECUSF::BROWN_N "Nick BROWN, Conseil de l'Europe" 16 lines 31-JUL-1991 13:58 -< What kind of errors do you expect ? >- -------------------------------------------------------------------------------- I presume the term "RMS file" means (to the author of .0) an indexed or similar file created with "the kind of RMS calls most programmers never get round to making"... If you have any "bad" files (ie those where a bad block has been replaced), these should show up with FORCEDERROR when you copy them. Either BACKUP or COPY [*...]*.* to NLA0: and see if you get any errors of this type. If you're getting lots of erros, I presume that you have already made a tape backup. BACKUP/VERIFY tends to tell you more about the destination medium than the source; the asusmption is that in a disk to tape backup, the tape will be the source of 99.99% of errors. Digital build a lot of redundancy into their disk drives (and controllers, when they don't make the drives, as in the case of the RD53) to ensure that the odd bad block or other error will not mess up your data. ================================================================================ Note 216.3 RD53 tres malade 3 of 8 DECUSF::LEGUEVA_A "Alex Leguevaques FOCEPY Auxerre" 15 lines 1-AUG-1991 15:38 -< Precisions >- -------------------------------------------------------------------------------- Quand je parle de fichiers RMS ,je veux parler de fichiers de donnees, par opposition aux fichiers texte ,executable et autres. Desole pour la confusion. J'ai bien sur des sauvegardes (quotidiennes et mensuelles sur un an,plus quelques autres) mais ma question etait en fait : Plutot que de tout verifier(tres long et impliquant de faire ca la nuit,notre MicroVax II etant surcharge en ce moment de 8h a 21h) n'est-il pas possible,a partir de l'errorlog et des blocks logiques qui y sont mentionnes,de deduire quels sont les blocks virtuels correspondants,et a quel fichier appartiennent les dits blocks ? Sinon,pour l'instant aucun utilisateur n'a essaye de m'assassiner, mais je ne suis malgre tout pas rassure du tout. A.L. ================================================================================ Note 216.4 RD53 tres malade 4 of 8 DECUSF::BROWN_N "Nick BROWN, Conseil de l'Europe" 16 lines 1-AUG-1991 16:34 -< I don't think (!) you need to worru >- -------------------------------------------------------------------------------- If a block has gone bad which is part of a file, you will see the FORCEDERROR flag as soon as you read the block. Typically a bad block is detected when F11 writes to a given logical block. At that point, the controller revectors the logical block, the write is retried, and the error log entry is updated. On a non-DSA disk such as the RD53, the controller attempts to emulate the DSA concept of 100% error-free logical blocks. I'm not completely sure how far the DSA emulation goes. Certainly the BADBLK.SYS file on these disks can be non-empty, so there can be bad logical blocks. On a DSA disk (RA, RF) BADBLK.SYS is always zero-length; there are (by definition) NO bad logical blocks on a DSA disk. I'm almost certain that if you don't have FORCEDERROR, even on an RD disk, that your file is OK. ================================================================================ Note 216.5 RD53 tres malade 5 of 8 DECUSF::FOUCHET_F "François FOUCHET" 14 lines 7-AUG-1991 00:39 -< Precisions >- -------------------------------------------------------------------------------- > these disks can be non-empty, so there can be bad logical blocks. On a > DSA disk (RA, RF) BADBLK.SYS is always zero-length; there are (by > definition) NO bad logical blocks on a DSA disk. C'est pas tout a fait vrai (c'est meme faux dans VMS File System Internals). En fait, en plus du fait de contenir les bad blocks d'un disque non DSA, BADBLK.SYS contiend les blocs restant de la division "nombre total de blocs du disque / cluster size du disque", et ce, meme sur les disques DSA. En ce qui concerne le lien entre un LBN et un fichier, il existe des bricos qui donnent ca. Si vous n'etes pas presse, je peux essayer d'en copier un ici (s'il n'y en a pas deja un). Mais ca ne sera surement pas avant mi septembre ... ================================================================================ Note 216.6 RD53 tres malade 6 of 8 DECUSF::LEGUEVA_A "Alex Leguevaques FOCEPY Auxerre" 8 lines 7-AUG-1991 09:32 -< Conclusion >- -------------------------------------------------------------------------------- Le disque en question a ete remplace et un BACKUP a revele un fichier indexe "malade",mais rien de grave. Par curiosite et au cas ou cela se reproduirait (le pb est survenu sur un disque qui venait deja en remplecement d'un disque defectueux il y a 2 mois de cela !) je suis preneur du (des) brico(s),sachant qu'il n'y a plus urgence. Merci a tous. AL ================================================================================ Note 216.7 RD53 tres malade 7 of 8 DECUSF::FOUCHET_F "François FOUCHET" 2 lines 7-AUG-1991 15:27 -< Stay tuned ... >- -------------------------------------------------------------------------------- Ok, je note ca sur mes tablettes. Des que j'ai un VAX derriere mon clavier, je copie le brico dans VMS ... ================================================================================ Note 216.8 RD53 tres malade 8 of 8 DECUSF::RICHARD_M "Michel RICHARD - YLIS Informatiq" 16 lines 13-AUG-1991 19:36 -< En attendant >- -------------------------------------------------------------------------------- En attendant, je mets dans VMS un saveset NEWFILES.BCK qui contient une version modifiée d'un vieil utilitaire Decus. Il permet de trouver à quel fichier appartient un LBN donné, et aussi de sélectionner directement dans l'Index file des fichiers selon différents critères: taille, uic, nombre de fragments, nom Il fonctionne comme une "foreign command" je n'ai jamais eu le courage de le réécrire en utilisant le CLI. Il y a un help dans le saveset. Si il y a un problème pour le faire fonctionner, envoyez moi un mail.