[Coco] Another Coco Virtual Disk Util

[Walt Zydhek]

I used a slightly different  (but same result) in allocating the space and
creating the FD.SEG. I use a temporary copy of the bitmap, allocate space in
largest chunks possible, creating the FD.SEG. in multiple chunks if
necessary to fit the file. All before I write the file. After writing the
file, I write the new bitmap. This also helps in case there is a problem
writing the file,  the "used space" is not actually marked as used unless
everything was successful. I don't allocate more than necessary then free
unused sectors.

-Walt Zydhek

-----Original Message-----
From: coco-bounces at maltedmedia.com [mailto:coco-bounces at maltedmedia.com] On
Behalf Of Gene Heskett
Sent: Monday, October 21, 2013 8:38 PM
To: coco at maltedmedia.com
Subject: Re: [Coco] Another Coco Virtual Disk Util

On Monday 21 October 2013 22:27:42 Theodore (Alex) Evans did opine:

> On 10/21/2013 07:10 PM, Gene Heskett wrote:
> > Name confusion Alex, os9 has been calling that disk area from LSN1 
> > to
> > LSN$100 (max, or however many it takes) the FAT since its first 
> > release. The address of the / directory in LSN0 is for its FD sector 
> > to start in the next sector after the FAT, and the directory itself 
> > is the next 7 sectors in sequence.
> 
> I have never seen any actual OS-9 documentation that referes to that 
> area as a FAT.  The Level 2 documentation calls it a disk allocation 
> map and I haven't looked at my level 1 documentation, but I believe 
> that it calls it the same thing.  It doesn't even serve the same 
> function as a FAT.  It merely indicated what ckusters are and are not 
> allocated.  A FAT is a singly linked list of allocated regions for 
> each file.

In os9, that is referred to as the FD.SEG, and is part of the file
descriptor sector.  That is a series of 48 each 5 byte entries, where the
first is the LSN of the first (or next) piece of the file, 3 bytes, followed
by 2 bytes which is the length of that part of the file in clusters.  Every
file, including directories, has an FD.SECTOR that describes the file, and
where its at.  While this could be used to determine where free space that
can be used is located, locating, then reading, every FD.SECTOR on the disk
would be a very time consuming operation, so os9 has a separate allocation
map in a known place, between the disk's own descriptor in LSN0, and the
first FD.SECTOR describing the root directory.  Then writing a new file is
just a matter of finding out how big SAS is set to, and then searching
through this allocation map looking for a big enough space to write SAS
clusters of the file, something it can do about 500-5000 times faster.  It
then allocates SAS clusters, and writes the file till it runs out of file,
closes it and returns the unused portion of SAS to the free disk by clearing
those bits not used.  If the file is bigger than SAS clusters, another SAS
clusters will be allocated, a 2nd FD.SEG entry in the FD.SECTOR is composed,
and that process repeats till it has run of of room to create the 49th
FD.SEG entry, or the file has been written in its entirety.

> If you have a FAT the directory entry points to the first allocated 
> region. Each entry in a FAT indicated one of three things, the region 
> is unallocated, wht the next region in the file is, or that the region 
> is the last allocated region in the file.  As it happens (not 
> surprisingly considering that RS-DOS was developed by MS) this is 
> exactally the way the track 17 on an RS-DOS disk is layed out.

Applicable to the RS-DOS filesystem.  But don't they call that a GAT, for
Granule Allocation Table??

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)

In this world, nothing is certain but death and taxes.
		-- Benjamin Franklin
A pen in the hand of this president is far more dangerous than 200 million
guns in the hands of
         law-abiding citizens.

--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco