[comp.sys.amiga] Is AmigaDOS sane?

R38@PSUVM.BITNET (aka Marc Rifkin) (01/20/88)

I tried to post a similar message, but evidently, it did not make it
through.
  A while ago, I made the inevitable switch to CLI, and I now deal with
all of my file through that interface (or some shell of the like), and
I have noticed some quirks (if you could call them that) in the file
storage on my disks:
First of all, a newly formatted disk does not have even close to '880k',
I know there is usually some overhead used by the DOS, but HOW MUCH?
Also, I have noticed some inconsistencies in block allocation- such as
putting say 600k on a disk and then checking to find close to 100k free.
What is going on here?
     
Now, for some questions on the (infamous?) AmigaDOS 1.3 (1.?)-
I understand that the 'Fast Filing System' is designed to enhance hard drive
performance and is not compatible with the current floppy format. But,
is it possible to format a new floppy under this new format and use it
from there?
     
And finally, I read a few messages about the construction/use of audio
digitizers- I am interested in building one myself, but what confuses me
is just what signals to send to the computer (so the software can under
stand).  A-D is ok, but what kind of D?
     
Thanks very very very much!
.
PS:  68040 is in development, and it sounds like a BEAUTY!!
     
(this is a temporary non permanent signature)
    *******************************************************************
    *                                                                 *
    *       RAEGIS aka Marc Rifkin                                    *
    *         of Vertex, Inc.          132 Beaver Hall                *
    *                                  University Park, PA 16802      *
    *       R38@PSUVM                  (814) 862-6892                 *
    *              "May I have a shotgun, pleeze!"                    *
    *******************************************************************
     

page@swan.ulowell.edu (Bob Page) (01/20/88)

R38@PSUVM.BITNET (aka Marc Rifkin) wrote:
>First of all, a newly formatted disk does not have even close to '880k',

Oh?  How much does it have?  Let's count:

	2 heads * 80 cylinders/head * 11 sectors/cylinder ==> 1760 sectors.

	512 useable bytes per sector, plus
	16 bytes of sector label area per sector = 528 bytes/sector

Which is 528 bytes/sector * 1760 sectors ==> 929280 bytes, or 907.5K.
Note that I'm using the standard notation '1K' == 1024 bytes, unlike
some unscrupulous disk drive manufacturers who say it's only 1000
bytes [you know who you are].  If we don't count the sector label
areas, we have 1760 sectors times 512 bytes ==> 901120 bytes or 880K.

>I know there is usually some overhead used by the DOS, but HOW MUCH?

Two sectors are reserved for boot block info.  We'll throw them out
of our calculations right off the top.  Down to 879K, or 1758 blocks.
One sector is allocated for the root directory block.
One sector (on an 880k disk) is allocated for the disk block bitmap.

So, on a freshly formatted 880K disk, you'll have 2 blocks allocated,
and 1756 (or 878K) free.  'info' tells you this.  That's close to 880K.

Each file has a file header block - that's another block per file.
Each file has a number of data blocks ... 488 bytes can fit in each
data block, because there is an overhead of 24 bytes per data block.
So, an otherwise empty disk with one 6 'block' (six 512-byte blocks)
really will take up 8 blocks .. one for the file header, and seven
(488 data bytes in the first six + 144 data bytes in the seventh one).
That's an overhead of 33% or so.

If your file is bigger than 70272 bytes, you'll need one additional
block to hold some more information for the next 70272 bytes, and
so on.  So a 300,000 byte file would take not 300000/512 = 586 blocks,
but 300000/488 = 615 blocks + 1 file header block + 4 'extension'
blocks, or 620 blocks total.  That's about 5.8% overhead.

Of course, if you have a 500-byte file, you have two file blocks + 1
file header = 3 blocks, or 200% overhead.

>Also, I have noticed some inconsistencies in block allocation- such as
>putting say 600k on a disk and then checking to find close to 100k free.
>What is going on here?

Those aren't inconsistencies.  See above calculations.

>is it possible to format a new floppy under this [fast file system]
>format and use it from there?

No, the floppies already have a file system handler process assigned to
them when they come up (it's in kickstart).  Of course this is conjecture.

..Bob
-- 
Bob Page, U of Lowell CS Dept.  page@swan.ulowell.edu  ulowell!page
"I don't know such stuff.  I just do eyes."  -- from 'Blade Runner'

rokicki@rocky.STANFORD.EDU (Tomas Rokicki) (01/20/88)

> If your file is bigger than 70272 bytes, you'll need one additional
> block to hold some more information for the next 70272 bytes, and
> so on.

Actually, this occurs every 35,136 bytes, I believe.  The total
blocks taken by a file of $n$ bytes is

	2 + floor((n-1)/488) + floor((n-1)/35136)

I usually don't subtract the 1, I usually use the formula

	2 + floor(n/488) + floor(n/35136)

when seeing if there is space on a floppy for a file, to take into
account possible off-by-1 errors.  (Note that the floor function
is the same as integer division in C with positive numbers.)  So
the biggest file you can put on a floppy (figure it out!) is

	845,703 bytes

but you can only put

	439 1024 byte files

or

	879 1 byte files

or

	146 5120 byte files

on a floppy diskette.

Have fun!

rokicki@rocky.STANFORD.EDU (Tomas Rokicki) (01/21/88)

> The biggest file you can put on a floppy (figure it out!) is
> 
> 	845,703 bytes

Oops!  That should have been 845,216 bytes.  My error.  Also remember
that each directory, no matter how big or deep, takes  exactly one block.
So hierarchical directory trees are cheap, at least in a space sense.

-tom

cmcmanis%pepper@Sun.COM (Chuck McManis) (01/21/88)

In article <30217R38@PSUVM> R38@PSUVM.BITNET (aka Marc Rifkin) writes:
> First of all, a newly formatted disk does not have even close to '880k',
> I know there is usually some overhead used by the DOS, but HOW MUCH?
> Also, I have noticed some inconsistencies in block allocation- such as
> putting say 600k on a disk and then checking to find close to 100k free.
> What is going on here?

The maximum data storage on a floppy disk is 80 Cylinders * 22 sectors/Cyl
* 488 bytes/sector or 838K, however DOS reserves two blocks for booting,
1 block for the root block, and one block for the bitmap page. Thats
4 blocks or 1.9K (Note K = 1024), now a file needs at least one block
for the file header and one block for every 'extension' I believe you 
get 72 pointers/file header so every 73 blocks, one is needed to hold
the pointers Since we have 1756 blocks left divide that by 73 gets us
24 and some change, or 25 blocks to hold the file header and pointers.
So the biggest file you could hope to put on a floppy would be 
1760 - 4 - 25 = 1731 blocks or 824.9K bytes.

Note that 'info' lies to you about how much space is available on the
disk because it multiplies free blocks by '512' rather than the value
in BYTESPERBLOCK. My version of the Info command let you see the 'real'
sizes. 
     
>PS:  68040 is in development, and it sounds like a BEAUTY!!

And I here the 80586 has a virtual Cray X-MP mode! :-)

--Chuck McManis
uucp: {anywhere}!sun!cmcmanis   BIX: cmcmanis  ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.

daveh@cbmvax.UUCP (Dave Haynie) (01/21/88)

in article <30217R38@PSUVM>, R38@PSUVM.BITNET (aka Marc Rifkin) says:
> 
> First of all, a newly formatted disk does not have even close to '880k',
> I know there is usually some overhead used by the DOS, but HOW MUCH?
> Also, I have noticed some inconsistencies in block allocation- such as
> putting say 600k on a disk and then checking to find close to 100k free.
> What is going on here?

Newly formatted disk has 2 heads, 80 cylinders/head, and 11 blocks/cylinder
available from the trackdisk.device's point of view.  That amounts to
2 * 80 * 11 = 1760 blocks.  Each block can store 512 bytes, so you get
a total of 901,120 bytes, or exactly 880K, of low level storage on each
floppy.  And blocks are never subdivided, so even if you're not using the
whole block, you still pay for it.  The DOS does eat some of this as overhead
before you do anything.  Two blocks are reserved at the beginning of the disk
(for Bootblock), plus 1 for ROOT (in the center of the disk) and 1 for bitmap
(near the ROOT), leaving 899,072 bytes free.  For each subdirectory, you use
one block.  That's the easy part.

Files complicate things a bit.  Each file needs a file header block, which
takes one block, and generally at least one block for data storage.  Each
data storage block takes 24 byte for DOS overhead, leaving 488 bytes for
the actual data.  Each file header stores pointers to 72 data blocks.  If
there are more than 72 data blocks in a file, an extension block must also
be allocated.  And if there's more than that, another extension, and so on.
So if you know how large a file is in raw bytes, you can figure out how
much it'll take to store the thing out on floppy.  Something like:

        BLOCKS = 1 + (RAWSIZE+487)/488 + (RAWSIZE+487)/(488*72)

                 ^           ^                       ^
             FileBlock   DataBlocks           ExtensionBlocks

The "+487" indicates that even one extra byte must be stored in a new block,
assuming integer division above (or the floor() function if not).

This implies that if I wanted to make one giant file on a formatted disk, I
could store 844728 bytes of data in it, or just under 825K.  Of course, if
you have no use for a single, 844728 byte file, you may choose to instead
store subdirectories and/or multiple files.  Still, that's not all that far
from 880K.  I don't know the level of overhead required in the filesystems
of other DOS's, but they don't give you files and directories completely
for free, either.

The standard overhead in each block is an array of 6 longwords.  These blocks
contain the checksum for that block (important on floppies, pretty useless 
on hard drives), various block pointers to parents and children, and often
a self-referential pointer.  This makes recovery of a disk something that
can be done pretty throughly.  Like, you can trash every directory on a
floppy, and still get back every single file, and even the disk's directory
structure.  Try that on MS-DOS some day.

Excuse any math errors in the above, once you get that Mathematics degree,
you have to surrender any and all ability in Arithmetic.

>     *       RAEGIS aka Marc Rifkin                                    *
-- 
Dave Haynie  "The B2000 Guy"     Commodore-Amiga  "The Crew That Never Rests"
   {ihnp4|uunet|rutgers}!cbmvax!daveh      PLINK: D-DAVE H     BIX: hazy
		"I can't relax, 'cause I'm a Boinger!"