Aucbvax.5746 fa.info-vax utcsrgv!utzoo!decvax!ucbvax!info-vax Tue Jan 12 19:45:22 1982 Re: VFY2 and multiple-volume sets >From KENNER@RUTGERS Tue Jan 12 18:52:49 1982 I think your problem with VFY2 has nothing to do with multiple volume sets but rather with disk caching. The manual which describes VFY2 (Utilities?) says that you should have disk caching off when you run VFY2 (or run it right after doing a MOUNT). What is happening is that the index file bitmap on the disk shows, e.g, index file block 12345 as in use, but the block contains a file sequence of 0 which is invalid. The index file bitmap in the ACP's cache may be different. I think that what's happening is that there may be preallocation of index file header blocks of some sort in memory (or something similar). I have seen this on our VAX as well. If it occurs right after a disk has been mounted and before any other activity, then its likely that the index file bitmap is bad -- if this is the only problem with it, the only effect is that you will loose file header space. Of course, it MIGHT be a problem with VFY2. A way to check is the following: If there are enough bad file headers, the REBUILD (done at mount or as a DISKQUOTA command) will fail. So if it doesn't but VFY2 reports LOTS of these things right after a mount then its probably a VFY2 problem. (By the way, block 12345 is not a deleted file because these look like (0,nnn) instead of (nnnn,0) (so that the sequence gets incrememented). I'm not exactly sure what VFY2 is displaying). We, however, have been unable, the time it really counted, to get VFY2 to find lost files on both volumes of a two-volume set. However, I'm quite sure that it worked at one point. Did you do something other than MCR VFY2 rootvol:/LO to get it to work? (The time we tried was when the first volume of a volume set had a head crash and we wanted to get files back from the second volume.) (I wouldn't bother SPR-ing any VFY2 bugs since I assume that V3.0 will have completed replacing all compatibility-mode code (including VFY) with native- mode code.) As to how to find out the file associated with a given fileid, the simplest way I know is MCR DMP TI:=real_volume:/FI:fid:fseq/HD where real_volume is the ACTUAL volume in the volume set its on. Of course this doesn't give you the directory its in, but you get the owner and the filename the file was created with. (Another way is to use MCR VFY2 real_volume:/LI and search the output (MCR VFY2 file=real_volume:/LI) for the wanted fileid (P.S., the way we ended up recovering the files we couldn't get VFY2 to find was to format this output into MCR PIP [ggg,uuu]=device:/EN:fid:fseq:2 commands!). ------- ----------------------------------------------------------------- gopher://quux.org/ conversion by John Goerzen of http://communication.ucsd.edu/A-News/ This Usenet Oldnews Archive article may be copied and distributed freely, provided: 1. There is no money collected for the text(s) of the articles. 2. The following notice remains appended to each copy: The Usenet Oldnews Archive: Compilation Copyright (C) 1981, 1996 Bruce Jones, Henry Spencer, David Wiseman.