[Coco] OS-9 sector allocation bitmap AKA LSN 1

[Gene Heskett]

On Sunday 02 September 2012 22:16:13 Willi Kusche did opine:

> Hi!
> 
> On Sun, Sep 2, 2012 at 7:04 PM, Gene wrote:
> > You may in fact have found a bug, but I wonder if its worth fixing. 
> > My system isn't up at the moment, but I assume one could clear that
> > bit with dEd of bd, and then check to see if it triggers anything, or
> > is even reported by free.  I really don't know, never having noticed
> > that.
> 
>     It would be interesting to see if that bit is set in the
> allocation bitmap on a freshly formatted disk.  Also, I need to look
> at the actual sector that bit refers to, to see if common data exists
> there on multiple disks.
> 
> Willi

Interesting line of thought.  I haven't walked around in the format code, 
understanding what I was reading, to that level of detail.  What I do know 
is that format, writes a track at a time, side at a time sequence, blindly 
over the whole disk, only updating the track and sector number in the just 
over 6k buffer, reusing the rest of the data.  Then it asks you for a disk 
name which it writes into LSN0 while writing the rest of the files systems 
data there. Then it goes into the verify phase. The FAT map is written 
during the verify phase, building it up until it runs out of memory 
buffering space if the floppy is big enough like an 80 track DS disk, backs 
up and writes the FAT, then goes back and finishes the verify, then backs 
up one more time and finishes writing the FAT, so any last bit foolishness 
would be there in the format code.  As for the data in that last sector, it 
should be the formats default data pattern, which for floppies was $E5 
repeated 256 times the last time I can recall looking.

There is no compression used on the floppies, while HD's generally do some 
sort of Run Length Limiting compression which typically gains the HD 
another 50% in capacity for sparse files containing mostly text etc.

Highly pre-compressed data, such as the more recent LR versions of zip or 
bz2 can output, will actually be silently expanded some on the HD surface, 
but this is completely hidden from us mortals by the drive, only coming 
into play when trying to predict how much a data tape used for archival 
storage will hold.  That discussion seems endless on the amanda list, but 
the bottom line there is that so amanda can track what has been written, it 
can only count the bytes sent down the cable to the drive so the best 
results are always obtained by letting amanda handle the compression which 
can quite handily beat the drives own version, with that function disabled 
in the drive.

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)
My web page: <http://coyoteden.dyndns-free.com:85/gene> is up!
	"Mach was the greatest intellectual fraud in the last ten years."
	"What about X?"
	"I said `intellectual'."
		;login, 9/1990