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 <[email protected]>
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.

You are viewing proxied material from gopher.quux.org. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.