From: CRDGW2::CRDGW2::MRGATE::"SMTP::CRVAX.SRI.COM::RELAY-INFO-VAX" 4-JAN-1991 09:39:07.92 To: MRGATE::"ARISIA::EVERHART" CC: Subj: RE: File system help needed; FIDs inconsistent Received: by crdgw1.ge.com (5.57/GE 1.80) id AA29309; Fri, 4 Jan 91 09:13:02 EST Received: From VENUS.YCC.YALE.EDU by CRVAX.SRI.COM with TCP; Fri, 4 JAN 91 05:47:53 PST Received: from BULLDOG.CS.YALE.EDU by Venus.YCC.Yale.Edu; Fri, 4 Jan 91 09:38 EST Received: from lrw.UUCP by BULLDOG.CS.YALE.EDU via UUCP; Fri, 4 Jan 91 08:36:25 EST Received: by lrw.UUCP (DECUS UUCP w/Smail); Fri, 4 Jan 91 08:10:04 EDT Date: Fri, 4 Jan 91 08:10:04 EDT From: Jerry Leichter Subject: RE: File system help needed; FIDs inconsistent To: INFO-VAX@KL.SRI.COM Message-Id: <9101041336.AA09244@BULLDOG.CS.YALE.EDU> X-Envelope-To: info-vax@kl.sri.COM If you do a directory of a file on the volume set, you get what you'd expect for the file id (SEQ,VER,RVN), where RVN is the relative volume number of the disk where the file actually resides. With a bound volume set of 2 disks, you always get a 1 or 2. Now, if you do a DUMP/HEADER on the file, it shows (SEQ,VER,0) instead of the correct RVN! The same occurs with DUMP/FILE_HEADER on INDEXF.SYS. What's going on? Swing reads directory files and is getting zeroes as well, which is what I suspect the problem is. Since zero is the correct RVN for disks which are not part of a bound volume set, it causes no trouble there. Can anyone explain why the FID is incorrect in INDEXF.SYS, but a directory command returns the correct FID? Any file system guru's out there? Well... here's a guess. A FID consists of three fields: File number, file sequence number, and relative volume number (RVN). Originally, each field was one word (16 bits) long. However, disks have now gotten large enough that it was reasonable to have more than 65K files on one of them; so a 16-bit file number started to become something of a limitation. To solve it, one byte was "stolen" from the RVN field. This gives a 24-bit file number field, and up to some 16 million files per disk, while still allowing 255 members in a volume set, which should be plenty. There's no direct way of telling, by looking at a FID, which format it is in. I'm not sure how you make the distinction. One guess is that you check the maximum number of files allowed on the volume - $GETDVI characteristic MAXBLOCK - though there may be a bit in the volume header somewhere that I haven't noticed. On the other hand, the documentation indirectly suggests that all newly-initialized disks use the new format. Few programs need to know: A FID should generally be treated as an opaque data object, understood only by the file system. Any program that tries to format FID's needs to understand the new format. Of the standard VMS utilities, I can think of a few off-hand that need to format FID's: DIRECTORY, DUMP, and ANALYZE/SYSTEM or /CRASH (for SHOW CHAN). There may be a few more. Obviously, some programs understand the new format, while others do not! The "stolen" byte was the less-significant one of the RVN. An RVN of 1 or 2 in the "old" format would have 1 or 2 in the less-significant byte, 0 in the more-significant byte. Look at the same data as being in the new format and the more-significant byte becomes the entire RVN, and appears to be zero; while the file number becomes (65536 or 131072) larger. So it appears that your disks have old-format FID's; DIRECTORY properly formats them (or perhaps just plain doesn't understand new-format FID's); and DUMP/HEADER and SWING think that (at least some, probably all) FID's are in the new format. -- Jerry