Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!usc!elroy.jpl.nasa.gov!ames!amdcad!amdahl!kim
From: kim@uts.amdahl.com (Kim DeVaughn)
Newsgroups: comp.sys.amiga.tech
Subject: Re: when is a block not a block?
Message-ID: <3fco02lsb9LE01@amdahl.uts.amdahl.com>
Date: 20 Jul 90 02:11:56 GMT
References: <6498.269a4527@vax1.tcd.ie> <648H02l0b8KM01@amdahl.uts.amdahl.com> <13237@cbmvax.commodore.com>
Reply-To: ked01@juts.ccc.amdahl.com (Kim DeVaughn)
Organization: Amdahl Corporation,  Sunnyvale, CA 94086
Lines: 50

In article <13237@cbmvax.commodore.com> jesup@cbmvax (Randell Jesup) writes:
>
> In article <648H02l0b8KM01@amdahl.uts.amdahl.com> I wrote:
> >
> >For example, a file I have is 135046 bytes long.  On an FFS device, the
> >fib_NumBlocks entry says 267 data blocks, whereas the file actually has only
> >264 data blocks.  And no, fib_NumBlocks isn't adding in the file's header
> >and extension blocks for you.  The file actually occupies 268 blocks total
> >(264 data, 1 header, 3 extensions).
> 
> 	Actually, it looks to be counting extension blocks as well as data
> blocks, but not header blocks (since you can have them while having no
> data at all).  One could argue this is more accurate, since those extension
> blocks are used in storing the data, though they don't contain data
> themselves.

Yeah ... that is what it looks to be ... but I've been burned by a "pretty
face" before, too :-)

Are you saying this is now the documented behavior for the fib_NumBlocks
entry (for the FFS), or is it still better to compute them yourself from
fib_Size, so as not to break in future releases?


> > be the case under V1.4 Kickstart which will support full variable sized disk
> > blocks.
> 
> 	In fact, this _did_ get in (though only for powers of 2, with some
> limits).  Don't ask me how to set them up, I haven't tried.  Useful if you
> have devices that have a minimum sector size of 1K or 2K, also reduces
> fragmentation at cost of increased loss from partially full blocks.

OK, I won't (yet, anyway :-) ) ... but can you say if the hash-table size
is still fixed at "72", and if it isn't fixed, how one finds out that
info (the field in the root block struct ?)

Also, will all the info on the file system finally get documented in
the RKM's (or elsewhere), now that the BCPL stuff is exorcised?  Or do
we still need to look to Bantam to provide the info on the filesystem?

Thanks, Randell ...!

/kim

-- 
UUCP:  kim@uts.amdahl.com   -OR-   ked01@juts.ccc.amdahl.com
  or:  {sun,decwrl,hplabs,pyramid,uunet,oliveb,ames}!amdahl!kim
DDD:   408-746-8462
USPS:  Amdahl Corp.  M/S 249,  1250 E. Arques Av,  Sunnyvale, CA 94086
BIX:   kdevaughn     GEnie:   K.DEVAUGHN     CIS:   76535,25