🚀 go-pugleaf

	After trying to understand the AOS/VS filesystem, I have become
more confused than ever. What I have tried to do, is to show how much _real_
disk space is used by a file or group of files. I have written a CLI command
to list 'f/len/index/elem/typ/l=filename', and then I have used 'awk' to
process this and calculate the numbers. However, the results are clearly
incorrect, and reflect my poor understanding of AOS/VS. Here's what I think
I know:

Each file has a length given in bytes. Given the element size for that file
(default 4 on our system), the real file size is just the length in bytes
taken up to the next multiple of the element size. (e.g. An element size of 4
means 4*512 = 2k bytes, so such files are allocated in 2k chunks).

But what about index blocks? OK, so I also count the number of index levels
in a file, and allow a block for each level (Is this correct? Are index blocks
true blocks, or blocks within a 2k chunk? In other words, does the system lose
4 blocks on the first index 'block' and use this for the next three?)

BUT! I have noticed DG's sneaky compression of files (executables) with large
blocks of nulls in them (am I right?), so that a file can seem large (in bytes),
while actually taking up much less disk space. (Is this only for PRV files?
Why doesn't the file system tell users the 'correct' size?)

Now for the *really* tricky part. Create an empty CPD. put a file in it
(length 0). Start adding data. Who knows how much space the file takes up!?
Does the SPACE command include the space taken up by directory entries? How
does one calculate that (Note that when one deletes the file, the CPD is not
'empty'. This presumably is the directory entry...?).

So if there are any Data General employees or hackers out there, maybe you
could enlighten me?
						Richard Brown

						(rab@murdu.mu.OZ.AU)
						   or
						(rab@murdu.ucs.unimelb.OZ.AU)