🚀 go-pugleaf

In article <648H02l0b8KM01@amdahl.uts.amdahl.com> kim@uts.amdahl.com (Kim DeVaughn) writes:
>Oh yes, one other thing, the comment on "HighSeq" (fib_NumBlocks) is wrong.
>The field *is* updated by the FFS ... it's just not accurate (usually off by
>2 or 3 blocks, but that depends on the file's size).
>
>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.

>"Please note that these structures assume a fixed, 512 byte disk block.  This
> is a valid assumption for filing systems up to V1.3.  However this will NOT
> 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.

-- 
Randell Jesup, Keeper of AmigaDos, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com  BIX: rjesup  
Common phrase heard at Amiga Devcon '89: "It's in there!"