[Info-vax] Request description of UFS for VMS person

[AEF]

On Apr 20, 4:34 pm, "Richard B. Gilbert" <rgilber... at comcast.net>
wrote:
> AEF wrote:
> >  Hi,
>
> > Can anyone here point me to a reference that describes the Unix file
> > system (UFS) at a level and detail similar to the that found in the
> > reference below? I've Googled for it and looked at a few books and had
> > no luck. Thanks!
>
> > Guide to OpenVMS File Applications, Section 1.2.2:
>
> >http://h71000.www7.hp.com/doc/731final/4506/4506pro_001.html#apps_fil...
>
> Most Unix books at least touch on the subject.

That's the problem: that's ALL they do. I've checked Wikipedia.
Superficial description. A while back I checked Wikipedia about
several file systems and the only one described in reasonable detail
was -- drum roll . . . . . . . . . -- VMS!

What is the structure of the "super block"? How are the group
cylinders organized and/or determined and made? What is their
structure? How are inodes found by the OS? Directories seem to be
mostly the same as in VMS: a one-to-one mapping of filenames to inode
numbers (FID's in VMSland). I did notice some strange extra bytes in
the equivalent of DUMP blah.DIR;1 output. I wonder what they are. Once
the inode number is found from the filename, how does Unix find the
actual inode? One Web page I read says some confusing words about a
single block in the super block listing a free block's address and a
pointer other "data blocks" containing 10 of them and more pointers
and I don't know -- it didn't make any sense to me.

(Speaking of DUMP <blah>.DIR;1: Why do only some versions of 'od' read
directory files? The version I have on a Solaris 10.something box -- I
think it's the gnu or gcc or Linux-like or whatever version --
complains that "Its a directory"? Well, duh. Another machine with
Solaris 8 could read it just fine. We're talking about dumping bytes
in a file. Is there something hard about this in Unix?)

In VMS you have INDEXF.SYS. When RMS, XQP, or whatever it is, is asked
to find the data in a file, it reads the directory, finds the
requested filename, learns its FID, goes to INDEXF.SYS finds the VBN
for the file-header offset by some formula I can't recall offhand, and
finally reads the file header with that number. And that file header
tells you all about the file and which blocks contain its data. There
is the bitmap in the INDEXF.SYS file that keeps track of whether a
file header is in use. There is the 3-number FID: number, sequence
number, relative volume number. Unix appears to only have the first.
There's the home block, the boot block, the backups thereof,
BITMAP.SYS, and so on. Where is the reference that describes the Unix
equivalents of these?

Then there's the mysterious VMS deletion process which I'd love to
learn. I only know about it from the strange ANAL/DISK errors about
file headers being busy, deleted, quasi-deleted, or whatever. I'd love
to learn about that too. [Fuzzy-memory-of-a-long-ago-event alert!] I
once learned a little about it and kept a sample lying around, but
it's been so long I can't recall just what that was! Wait, I think it
was a file header without a filename being entered in any directory.
If I have time I'll try to resurrect this. [Another fuzzy-memory-of-a-
long-ago-event alert!] I think I even asked this question (re the file-
deletion process) here once many years ago and if I did I never got a
good answer.

>
> What problem are you trying to solve?

I want to learn how UFS works at the level mentioned above. I don't
have any particular problem to solve. I just want to learn it out of
curiosity and in case I need it later.

I do know more or less about how hard and soft links work.

Thanks.

AEF