<<< DISK$DATA:[NOTES$LIBRARY]VAX_VMS.NOTE;1 >>> -< SIG VAX/VMS >- ================================================================================ Note 1270.0 HEADERFULL ?? 25 replies DECUSF::BROWN_N "Nick BROWN, Conseil de l'Europe" 20 lines 5-APR-1991 16:55 -------------------------------------------------------------------------------- We have an intermittent problem whereby users are thrown out of applications with the message SYSTEM-F-HEADERFULL (the SYSTEM-F- part I'm not so sure about, but it's HEADERFULL in any case). Please excuse the vagueness of this description, but it is an intermittent problem and our users are not too brilliant at reporting things exactly. According to the messages manual, this can happen if the index file is being extended. Presumably this might mean if a user adds the Nth file where INDEXF.SYS has N-1 entries, and while this is going on, someone tries to add the N+1th file. The disk is an RA90 with currently about 47800 files; INDEXF.SYS is 49200 blocks. I don't know how many multi-header files there are (is there an easy way to find out ? - we have DISKEEPER 4.0). No problems on other disks. Maybe an application creates LOTS of (temporary) files in a rush ? Maximum files on the disk is > 280000, so no problem there. DISKEEPER runs "after hours" only, never during user time. Only one disk has the problem. Thanks in advance for any ideas. ================================================================================ Note 1270.1 HEADERFULL ?? 1 of 25 DECUSF::THONON_D "Daniel Thonon SEMA-GROUP Meylan" 3 lines 5-APR-1991 17:05 -< Voir Release notes >- -------------------------------------------------------------------------------- Dans les release note VMS 5.4, il est dit qu'il y a des pb si le fichier index est trop fragmente. Il faut faire un backup/init sur un nouveau disque pour refaire le fichier contigu ================================================================================ Note 1270.2 HEADERFULL ?? 2 of 25 DECUSF::FOUCHET_F "François FOUCHET" 6 lines 5-APR-1991 17:12 -< C'est tres possible >- -------------------------------------------------------------------------------- Ca doit effectivement etre le probleme. En effet, il n'est pas possible d'avoir de header d'extension sur INDEXF.SYS (histoire de l'oeuf et de la poule). Comme d'autre part, les defragmenteurs ne touchent pas a INDEXF (celui qui y arrive va se faire un pognon fou en vendant ca a DEC). La seule solution, c'est effectivement le BACKUP/INIT (ou alors, detruire des fichiers). ================================================================================ Note 1270.3 HEADERFULL ?? 3 of 25 DECUSF::GERARD_G "G. Gerard ENST centre de calcul" 18 lines 5-APR-1991 17:23 -< backup is peut-etre the last resort >- -------------------------------------------------------------------------------- > The disk is an RA90 with currently about 47800 files; INDEXF.SYS is > 49200 blocks. I don't know how many multi-header files there are (is > there an easy way to find out ? - we have DISKEEPER 4.0). No problems > on other disks. Maybe an application creates LOTS of (temporary) files > in a rush ? Maximum files on the disk is > 280000, so no problem ^^^^^^^^^^^^^ murphy was an optimist. maximum files est le nombre maximum de fichiers *autorises* sur le disque: ca n'a *RIEN A VOIR* avec la taille de l'indexf.sys qui, lui, est cree pas grand et s'agrandit par paquets de 1000 (oui, MILLE) blocs lorsqu'il est devenu trop petit. la taille initiale de l'indexf.sys est donnée par le switch /HEADERS. Pour découvrir l'ampleur de votre infortune: dump/header/block=count=0 ddcu:[000000]indexf.sys. si la map est saturée, alors une seule solution: backup/image puis restore. Il me semble que backup donne la bonne taille a l'indexf.sys dans ce cas. ================================================================================ Note 1270.4 HEADERFULL ?? 4 of 25 DECUSF::CAILLAT_M "Michel" 8 lines 5-APR-1991 23:50 -------------------------------------------------------------------------------- > 49200 blocks. I don't know how many multi-header files there are (is Il y a un brico de BO qui vous le dira: VAXF90:DISKSTAT.MAR et VAXF90:COMMAND.MAR ================================================================================ Note 1270.5 HEADERFULL ?? 5 of 25 DECUSF::PAYEN_P "Patrice Payen AMOSDEC" 11 lines 8-APR-1991 09:35 -< Multi Header Consolidate >- -------------------------------------------------------------------------------- Si vous avez la version 4.0 de DISKEEPER/PLUS, il vous est possible grace a l'utilitaire DISK_ANALYSIS livre avec le produit de connaitre exactement le nombre de multi-header files sur chaque disque.(User's Guide pa 4-1) Apres cela, le programme Multi Header Consolidate (MHC), vous permettra de les consolider afin de reduire les entrees dans l'INDEXF.(User's Guide Chap 7) Je suis sur que cela va redre vos problemes. Si vous voulez plus de renseignement, appelez moi. ================================================================================ Note 1270.6 HEADERFULL ?? 6 of 25 DECUSF::FOUCHET_F "François FOUCHET" 20 lines 8-APR-1991 12:28 -< Je ne suis pas vraiment d'accord ... >- -------------------------------------------------------------------------------- Quelques questions au sujet de DISKEEPER/PLUS : C'est aussi gratuit que les bricos DECUS ? Vous avez regle les cas de corruptions de disque en cas de crash au mauvais moment ? Vous implementez deja la nouvelle QIO XQP ? Je pense que l'ingenering DEC sera tres content de votre solution pour defragmenter INDEXF. Pour le moment, et a ma connaissance, ils n'ont pas, eux, trouve de solution SAINE pour le faire ... Vous faites comme vous le souhaitez. Pour ma part, apres avoir lu les internes ODS 2, et les sources de XQP, j'ai arrete un defragmenteur (pas DISKEEPER d'ailleurs) qui tournait chez moi, histoire de dormir tranquille. NB: c'est une position personnelle. J'ai pas d'actions chez DEC (il suffit de regarder quelques autres de mes reponses dans la messagerie). ================================================================================ Note 1270.7 HEADERFULL ?? 7 of 25 DECUSF::BROWN_N "Nick BROWN, Conseil de l'Europe" 19 lines 8-APR-1991 12:35 -< It's as contiguous as I can make it... >- -------------------------------------------------------------------------------- OK, so I dumped the header of INDEXF.SYS (both with DUMP and my home-mode FRAG diagnostic, available now for $0.00). INDEXF.SYS (49200 blocks) contains fragments as follows: Count: 6 LBN: bla bla Count: 3 LBN: bla bla Count: 3 LBN: bla bla Count: 90 LBN: bla bla Count: 1002 LBN: bla bla Count: 1002 LBN: bla bla ... Count: 1002 LBN: bla bla I don't believe that 53 fragments is excessive for a 49200 block index file extended by 1000 blocks each time, but maybe this is a limit. Still checking for multi-header files. ================================================================================ Note 1270.8 HEADERFULL ?? 8 of 25 DECUSF::FOUCHET_F "François FOUCHET" 22 lines 8-APR-1991 13:05 -< Un petit calcul simple ... >- -------------------------------------------------------------------------------- Pour verifier, faites : $ DUMP/HEADER/BLOC=COUNT=0 disk:[000000]INDEXF.SYS Recuperez le "Map area offset" Ajoutez "Map area words in use" Comparez avec "Access control area offset" En cas d'egalite, vous avez perdu ! Si on regarde les valeurs par defaut, "map area offset est a 100", "access control area offset" est a 255, il reste dont 155 words libres pour decrire la map area. Suivant le format des "retrieval pointers", qui varie de 1 mot a 4 mots, ca vous fait 155 a 38 elements dans la map area. Vous avez une solution rapide, si vous utilisez un ACL sur INDEXF.SYS. Vous gagnerez de la place dans le header en supprimant un ou plusieurs ACE. Dans le cas contraire, seul BACKUP/IMAGE/NOINIT peut vous sortir de la PROPREMENT. ================================================================================ Note 1270.9 HEADERFULL ?? 9 of 25 DECUSF::SMANS_M "Michel Smans, C.I.R.C., Lyon" 6 lines 8-APR-1991 15:31 -< autre source de Pbs. >- -------------------------------------------------------------------------------- a .7: il faut aussi se souvenir que INDEXF.SYS ne peut PAS avoir de header d'extension! Il est donc possible d'avoir un probleme des qu'on depasse 38 "morceaux" comme l'indique FF en .8, et meme avant pour les fanas d'ACL!!! ================================================================================ Note 1270.10 HEADERFULL ?? 10 of 25 DECUSF::DELAFOSSE_G "Gilbert DELAFOSSE - UTC" 9 lines 8-APR-1991 16:06 -< more about DISKEEPER vs XQP et ODS2 >- -------------------------------------------------------------------------------- questions au sujet des questions sur diskeeper Pour l'instant je dormais encore tranquille (peut etre a tort) Mais que se cache derriere le remarques au sujet de XQP et ODS2. juste histoire d'avoir quelques infos pour me rendormir plus tranquile apres avoir pris eventuellement les mesures qui s'imposent. ou peut-on trouver le(s) outil(s) ou bricolo(s) equivalant(s) ================================================================================ Note 1270.11 HEADERFULL ?? 11 of 25 DECUSF::GERARD_G "G. Gerard ENST centre de calcul" 2 lines 8-APR-1991 16:27 -< vms:frag >- -------------------------------------------------------------------------------- j'ai mis dans VMS: frag.mar, qui donne quelques informations utiles sur l'etat de l'indexf.sys. C'est un brico de decus revu et modifie. ================================================================================ Note 1270.12 HEADERFULL ?? 12 of 25 DECUSF::FOUCHET_F "François FOUCHET" 29 lines 8-APR-1991 17:09 -< Pour dormir tranquille >- -------------------------------------------------------------------------------- > Mais que se cache derriere le remarques au sujet de XQP et ODS2. C'est fort simple : certaines infos ODS2 sont liees. Pour les mettre a jour, il faut 2 (voire plus) QIO distinctes. Si votre machine crashe entre les 2, votre disque est mort ! Les fabricants de defragmenteurs MENTENT SCIAMENT lorsqu'il annoncent leur produit sur a 100%, etant donne que, pour le moment, c'est techniquement infaisable. Simplement, ils estiment que la probabilite de tomber dans un cas de ce type est faible, et qu'il se passera un moment avant qu'on arrive a le leur prouver. Ou chechent simplement a vendre leur soupe. Si vous voulez rire, faites ce que j'ai propose a mon revendeur : demandez lui un papier signe, sur lequel il vous annonce que son defragmenteur est fiable du point de vue technique et qu'il indique que, conceptuellement, il n'y a aucun risque de perte de donnees. Ajoutez a ca une clause du style "1 Mo perdu par le defragmenteur = x KF", et gagnez de l'argent sur son dos ... Pour sa part, le mien (une SSCI connue dans le monde DEC, et que je denoncerais pas, meme par MAIL), a refuse de s'engager, en pretextant que le concepteur, joint par un coup de fil, l'avait rassure sur ce sujet (dans le style "faites moi confiance"). Ce qu'il faut savoir, c'est que DEC devrait modifier XQP de facon documentee, afin de rajouterer une primitive de deplacement de fichier. Le code de XQP saura detecter un deplacement non termine, et corriger le probleme (rollback). Aujourd'hui, dans le meilleur des cas, on perd le fichier. Dans le pire, on ne monte meme pas le disque. Entre les 2, une serie de blocs doublement alloues, et autres bricoles du meme genre. Choisissez votre camp, en connaissance de cause ... ================================================================================ Note 1270.13 HEADERFULL ?? 13 of 25 DECUSF::FOUCHET_F "François FOUCHET" 13 lines 8-APR-1991 18:11 -< Enjoy >- -------------------------------------------------------------------------------- Tant qu'on est a parler de fragmentation de disque, j'y vais de mon obole dans VMS:. Je viens de mettre : - FRAG_FREE.MAR : donne l'etat de fragmentation de l'espace libre d'un disque (nombre de blocs, nombre de "trous", pourcentage de l'espace total par tranche). - FRAG_LIST.MAR : donne la liste des fichiers ayant "N" headers d'extension. - SHOW_LBN.MAR : liste le contenu de la map area de tous les fichiers d'un disque (difficilement utilisable comme tel, mais peut donner de bonnes idees pour un eventuel brico). ================================================================================ Note 1270.14 HEADERFULL ?? 14 of 25 DECUSF::BROWN_N "Nick BROWN, Conseil de l'Europe" 31 lines 8-APR-1991 18:44 -< Let's analyze the risks >- -------------------------------------------------------------------------------- I used to be as opposed to defraggers as FF (.12). Since I have had my current job and used DISKEEPER I have changed my mind a bit. Of course there is a finite chance of losing data. Nonetheless, the dangerous operations don't happen very often; Digital cooperates VERY closely with the defragger makers (having created the defragger market by telling people that fragmentation is a problem, they can hardly avoid this); and Digital committed itself at DECUS Europe in 1989 to providing hooks in VMS to allow defraggers to work. There is of course a finite chance when you follow Digital's approved method of defragging (backup/restore), that one or more of your backup tapes is unreadable, even when made on Digital tapes on a Digital tape drive. Digital also will not sign an agreement of the order of "1 MB lost on bad tape / tape drive / head crash / RdB bug == nM$". Everything is a question of confidence in quality and the relative likelihood of error. If I have to come in at the weekend and backup an RA90 to 8 tape reels, twice (bad tape !), and then restore it, then by the end of Saturday evening I am quite likely to make a hideous mistake and delete something... Our safeguard is simple (though probably only 99.9999% safe): we only let DISKEEPER work on files older than 24 hours (which are on the backup). So we anticipate that we will "probably" survive "most" events. I am sure that if many entire disks were getting trashed that the DECUS grapevine would have told us by now (I hope). To summarise, I reckon there are about 10 points in my system more likely to lose data than my defragger. Once I have got rid of them (RdB, users, rotating magnetic media), then I'll put DISKEEPER top of my list. ================================================================================ Note 1270.15 HEADERFULL ?? 15 of 25 DECUSF::BROWN_N "Nick BROWN, Conseil de l'Europe" 3 lines 8-APR-1991 18:45 -< Thanks >- -------------------------------------------------------------------------------- By the way: thanks for the help on .0. It turns out that we initialised the disk without specifying /HEADERS, so we will have to wait for a convenient weekend and start again... ================================================================================ Note 1270.16 HEADERFULL ?? 16 of 25 DECUSF::DIAKONOFF_N "Responsable programmathèque" 21 lines 8-APR-1991 19:16 -< DEC mène devant Diskeeper. >- -------------------------------------------------------------------------------- Pour répondre à FF, effectivement il existe un petit risque en employant Diskeeper. Mais il existe un plus grand risque en employant les nouvelels versions de VMS. Aujourd'hui : Les nouvelles versions de VMS avec des utilitaires comme BACKUP, COPY et le fameux bug XQP m'ont fait perdre plus de 1 GO (Tous cumulés et avant que je ne m'aperçoive du Bug de VMS). Diskeeper : 0 octet !!!! Seul le disque système est traité par BACKUP/IMAGE. As tu demandé à DEC le même papier ? Te l'a-t-il signé ? De toute façon, il est certain qu'il faut faire attention, mais je pense hônnetement qu'en faisant d'abord le BACKUP/IMAGE des dsiques et en passant après 3 à 4 passes de Diskeeper, le risque est minime. Je crains plus les attérissages incontrôlés des têtes de lecture et la génération de bad blocks sur le disque. PS : Moi non plus, je n'ai pas d'actions chez DEC, ni chez Diskeeper. ================================================================================ Note 1270.17 HEADERFULL ?? 17 of 25 DECUSF::DELAFOSSE_G "Gilbert DELAFOSSE - UTC" 28 lines 9-APR-1991 08:55 -< si je pouvais faire autrement ... ! >- -------------------------------------------------------------------------------- Je suis ici depuis 5 mois et mon probleme etait le suivant: - Diskeeper etait disponible sur le site - Tous mes disques sont pleins a plus de 90%. La moyenne est de 93% ce matin Les solutions envisageables etaient: - BACKUP/RESTORE sur tous les disques de facon reguliere. Mais cela necessite des arrets systeme. (IGNORE=INTERLOCK ne permet pas de s'en sortir proprement). Donc arrets systeme a repetition et/ou heures supp _ BACKUP/RESTORE des disques (pour etre sur d'une sauvegarde faite proprement). Puis utilisation de Diskeeper avec discernement Il y en avait peut etre d'autre(s) Bien sur la meilleure etait : 1) Buy more disk(s) & HSC controler(s) 2) Eduquer les utilisateurs (purge ca existe) mais allez persuader un utilisateur qu'avoir 25 versions de certains fichiers ca n'est pas bien (ou que les messages mail d'avant le deluge on peut les detruire) les inconvenients : delais pour 1 et 2, couts pour 1, changement d'habitude pour 2 DONC je suis un IS satifait par Diskeeper, bien malgre lui (ie si je POUVAIS m'en passer cela m'arrangerait bien) . En cela je rejoins Nick Gilbert ================================================================================ Note 1270.18 HEADERFULL ?? 18 of 25 DECUSF::DIAKONOFF_N "Responsable programmathèque" 6 lines 9-APR-1991 09:38 -< Une idée pour les versions : >- -------------------------------------------------------------------------------- Nous avons dans notre procédure de sauvegarde mis VOLONTAIREMENT après le BACKUP/IMAGE de nos disques un PURGE/KEEP=2 sur les disques utilisateurs. Pour le moment PERSONNE n'est venu me réclamer un fichier version ;-2 ou ;-3. Cette procédure est en place depuis 3 ans ... ================================================================================ Note 1270.19 HEADERFULL ?? 19 of 25 DECUSF::GRACIA_J "José GRACIA - GRL/ELF Lacq" 10 lines 9-APR-1991 10:14 -< Etre SI...ou femme de menage! >- -------------------------------------------------------------------------------- Mes utilisateurs ont ete avertis des l'origine que seules les 3 dernieres versions etaient considerees et qu'en cas de peril sur un disque je me reservais le droit de lancer unen aveugle un pur/keep=3 pour palier a leur flemme de faire le menage. Ca a du arriver 4 ou 5 fois et personne n'est venu reclamer. Dans ces cas la je le fais avec un log et je repere les "gourmands". De toute facon, sauf developpement intense, ce qui est rare chez moi (ceci explicant aussi ma position) au dela de la 3eme version je peux avec un haut degre de probabilite recuperer sur le BACKUP de la veille). Mais chaque site a son contexte et il est difficile de generaliser. ================================================================================ Note 1270.20 HEADERFULL ?? 20 of 25 DECUSF::GERARD_G "G. Gerard ENST centre de calcul" 1 line 9-APR-1991 10:30 -< directory version limit >- -------------------------------------------------------------------------------- moi, je fais un set dir/version=3. personne ne râle. ================================================================================ Note 1270.21 HEADERFULL ?? 21 of 25 DECUSF::DELAFOSSE_G "Gilbert DELAFOSSE - UTC" 7 lines 9-APR-1991 11:27 -< ouais, j'aurais aime >- -------------------------------------------------------------------------------- moi aussi j'ai dit que j'allais faire ... et la ca a rale AVANT ... et les chercheurs il faut pas trop les violenter. moi j'ai plutot l'impression qu'il cherchent ce qu'il y a dans la version ;-n pour certains (mais je suis mauvaise langue ...) j'ai jamais pu travailler avec plus de 2 ou 3 (maximum) versions apres je suis limite par ma petite cpu personnelle ================================================================================ Note 1270.22 HEADERFULL ?? 22 of 25 DECUSF::GERARD_G "G. Gerard ENST centre de calcul" 3 lines 9-APR-1991 11:37 -< faut pas demander leur avis. >- -------------------------------------------------------------------------------- moi aussi j'ai dit que j'allais faire ... ^^^^^^^^ %SYSMGR-F-FATAL, fatal user protocol error j'ai rien dit... j'ai fait ...ils ont constaté. ================================================================================ Note 1270.23 HEADERFULL ?? 23 of 25 DECUSF::BROWN_N "Nick BROWN, Conseil de l'Europe" 32 lines 9-APR-1991 16:56 -< Devious ideas >- -------------------------------------------------------------------------------- Directory version limit is IMHO to be avoided if possible. A nightly purge down to N versions will achieve the same effect in most cases. Quite often I do something like: - come in in the morning to work on program BLURK.C, currently ;5. - edit BLURK.C several times, compile each time, finally get my new idea for functionality working. - sometimes I even do a PURGE/SINCE=TODAY, although that does not affect this argument; I might have had 10 bersions in the meantime. - decide after lunch that I don't like the new functionality, so delete all versions from today and go back to ;5. - obviously, with a directory version limit I would be profoundly shafted, as they say, having to recover my file from the end of an 8mm tape (on a drive which is busy 16 hours a day making backups). The only place I use a version limit (of 1 !!) is on a PCSA server for file services. DOS users don't expect to be able to get old versions, which is why their editore have .BAK files. But in other user environments, the ability to effectively have old versions under DOS might be a PCSA selling point. We do a purge to 2 versions nightly and a purge to 1 version of all files older than a week. The disks still get full, but at least there is more useful stuff on them. My advice to keep your disks in good condition cheaply (and confuse your management) is to make a big file (say 25% of the disk) when you initialise it, then SET FILE/REMOVE it. It will sit there as a nice contiguous reserve until you need it; then you just do ANALYZE/DISK/REPAIR to get the space back. This also enables you to justify a claim for a whole weekend's overtime "spent archiving and compressing", when in fact you ran a batch job on Friday at 8 pm and went sailing... ================================================================================ Note 1270.24 HEADERFULL ?? 24 of 25 DECUSF::GERARD_G "G. Gerard ENST centre de calcul" 6 lines 11-APR-1991 15:57 -< set watch/class=bug=backup >- -------------------------------------------------------------------------------- A signaler un détail quand même: $ BACKUP/noinit s'asseoit avec finesse et lourdeur sur le qualifier /HEADERS en recréant l'indexF.sys quand vous faites une restauration /IMAGE. Il recrée en effet l'indexf.sys à la taille de celui existant au moment de la sauvegarde/image. Solution préconisée par la telebase: restore/noimage en faisant gaffe aux links et aux fichiers temporaires. ================================================================================ Note 1270.25 HEADERFULL ?? 25 of 25 DECUSF::PETIT_JP "Jean-Pierre PETIT" 3 lines 4-MAY-1991 17:34 -< A vos lasers >- -------------------------------------------------------------------------------- Vu l'intérêt exprimé par la communauté pour le file system, je place dans VMS:ODS-2.PS_Z les slides d'une présentation effectuée il y a plus d'un an sur ce sujet.