[Coco] Biggest OS-9/Nitros-9 HD?

[Gene Heskett]

On Saturday 24 September 2005 16:55, Dave Kelly wrote:
>Gene Heskett wrote:
>>>byte x 8 bits = 2048 sectors of storage x 256 (sector size) =
>>>624,280 hard disk size possible.
>
>I'll accept your 524,288 if you accept that at the time I multiplied
>that this morning I had a hurricane in the neighborhood.
>
Absolutely Understandable.

>> You are calulating how many clusters the disk can contain I take
>>it.  But kcalc gives me 524,288 clusters for 65536 (maximum FAT
>>size) x 8 (bits per byte). That translates to a maximum disk size
>>if a cluster is 1, of 134,217,728 bytes.  Changing the cluster
>>size by powers of 2  is one option and the code is in rbf.mn to
>>handle this.
>
> This is what I remember, although I have had a couple of dreams
> since I first conceived this understanding :)

Bad ones no doubt.

> The storage area on the disk that tells if a sector is in use is of
> size sector, 256 bytes. Each bit in that sector that is set
> denotes that a sector is in use, if the 3rd bit of the sector is
> set, the 3rd sector is in use, and not to be overwriten.

Thats correct Dave, _if_ the cluster size is 1.  If its two, then each
bit represents 2 sectors (512 bytes) , 4, then its 4 sectors or 1kb of
disk per bit. 8=2048 bytes of disk, 16=4096, etc etc.

> If the above is correct then 256 x 8 = 2048 places are alloted to
> mark a cluster in use.  Each cluster is one sector in size or 256
> bites.
 
Only if the cluster size is 1.  For a cluster size of 8, then each
bit in the FAT represents 2048 bytes worth of disk.

> My understanding is that 48 - 5 bite date units at the end of the
> file descripter were there only to allow the file to be spread over
> the entire disk if needed, or where ever there was an empty sector
> available.

Yes, each one divided into a 3 byte Logical Sector Number, and a 2
byte length.  It was this last item in the rbf.mn's (its been fixed
now) that we thought maybe it was safe to use a bit as an archival
bit.  It worked great till the coco's files started to grow, and use
the 47th of these 'bins'.  The algorythm that stops the clearing of
bits in the fat when a file is deleted uses the 2 byte size as a
trigger to clear bits in the FAT, but since the LSN of the 48th
segment is $00 00 00, then the first sector was then cleared.  The
next write then overwrote LNS0.  Boom.  Unrecognizable disk without
LSN0's valid contents.  I was aware of that, and usually ran with a
dmode SAS=40 (or more) which reduced the number of bins sufficiently
that it wasn't a problem.  But several people did lose their drives,
and without the resources and knowledge to be able to call dEd on the
drive, and manually restore a valid LSN0, they had no choice but to
format the drive and lose all their life history.
  
If a reader here is reading this, my apologies if you were one who
was burnt.

I'm an old hand at that, the first B&B kit I had had this nasty habit
of reading the FAT and handing the OS a fully zeroed out sector.  I
fought with it, replaced the controller in the B&B twice, replaced the
drive once, and never managed to nail down the cause.  That thing cost
me several hundred megabytes of data, 8 to 16k at a time from
overwriteing good files when it thought the area was free.  After a
while and quite a bit of education I had a copy of LSN0 on a floppy
just for insurance, along with a little B09 routine to re-install it. 
Then I got a disto and a scsi drive and discovered it wasn't an os9
bug as it never happened again.

All because I, and the author of backar, thought it would be nice to
be able to do incremental backups by backing up anything with that
bit set in its file descriptor, which was set by any write to the
file, and then clearing the bit.  A good idea, with very disastrous
side effects under the right conditions.  And I still, 10 years
later, haven't managed to come up with a bit anyplace in the FD that
we could use, each and every bit is committed one way or another.

So we are to this day, stuck with backing up everything when we do a
backup as there is no way in os9 to mark a file as changed.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.35% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.