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

[Bob Eager]

On Tue, 21 Apr 2009 01:17:48 UTC, AEF <spamsink2001 at yahoo.com> wrote:

> 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!

Did you look at the references in the Wikipedia article?

> How are inodes found by the OS?

(the following isn't the whole story, I know, but it may help).

They start at a fixed block number. That number is in the super block.

> 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?

Simple arithmetic; the i-list (which isn't a file, unlike INDEXF.SYS) is
contiguous and preallocated. Once one knows the start blck, finding an 
i-node is trivial.

> 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.

What it says. The free block data structure is a list (several lists) 
rather than a bitmap.

> (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?)

Nothing at all; just a silly restriction. I bet that 'cat dirname  od' 
would work.

> 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.

Pretty well exactly what UFS does. Reads the directory, finds teh 
requested filename, learns the i-number, goes to the i-list, directly 
gets the i-node. And the i-node tells you all about the file and which 
blocks contains its data.

> There
> is the bitmap in the INDEXF.SYS file that keeps track of whether a
> file header is in use.

There isn't a bitmap, but it keeps track somehow.

> There is the 3-number FID: number, sequence
> number, relative volume number. Unix appears to only have the first.

Sequence number is merely a sanity check and isn't operationally 
necessary (although it's quite a good idea). RVN is only necessary if 
files span multiple volumes, which on modern disks is unlikely anyway.

> There's the home block

Super block.

> the boot block

It's not a file, but it's defined in the manual pages for 'boot'.

> the backups thereof

Defined in the 'newfs' program.

> BITMAP.SYS

There isn't one.

> 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'd start by reading the papers mentioned. The Berkeley FFS is a 
development of UFS with nice things such as snapshots. Go to 
www.freebsd.org and follow the documentation links....

-- 
Bob Eager