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

[AEF]

On Apr 21, 2:44 am, "Bob Eager" <rd... at spamcop.net> wrote:
> On Tue, 21 Apr 2009 01:17:48 UTC, AEF <spamsink2... 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?

Oops! Forgot. I'll take a look later.

>
> > 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 towww.freebsd.organd follow the documentation links....
>
> --
> Bob Eager

Thanks! I'll digest this later when I have more time. Thanks much!