[Coco] Question for those familiar with rbf.mn

[Gene Heskett]

On Sunday 01 February 2015 03:41:54 Allen Huffman did opine
And Gene did reply:
> > On Feb 1, 2015, at 2:21 AM, Gene Heskett <gheskett at wdtv.com> wrote:
> > 
> > Generally, that write will fail, but if it did, I would not kill the
> > process, I would hop over to another window and cut the sas in half
> > with dmode, effectively making less than normal sas sized bits of
> > the drive usable.
> 
> Clever.
> 
> > The last time I ran it, it was way more than 20 hours.  But I haven't
> > run it in probably 10 years now.
> 
> Yeah, once I got two SyQuest EZ135 drives, my defrag was dsave to
> another platter ;-)  That’s actually Microware’s official response
> to fragmentation, too. Or was when I was there.
> 
> > I suspect the majority of the time is being spent looking for a sas
> > sized place to put it. 128(131 something in decimal) megs is the
> > largest that can be represented in the FAT when the cluster size is
> > 1.  The system does, or did, keep track and did not have to search
> > the whole FAT in the past except for the first write after a reboot.
> >  After that it got noticeably faster when I was still using a Maxtor
> > 7120s drive on a 4n1 controller.
> 
> With 64K for the FAT, I don’t expect it to be loading that in memory
> and keeping it around.
> 
> > I have 2 identical seagate hawk 1Gb drives on my system, one of which
> > is only formatted for about 490 megs for os9, the remainder
> > available for HDBDOS and vdisks, so if I ever wanted to, I could
> > setup several more HDBDOS "partitions" of 256 disks each since3 each
> > such allocation is just over 80 megs.  The other I formatted all for
> > os9.  Drive 0 uses a cluster size of 4 sectors, while drive 1 (/s1
> > in my  lashup) uses a 16 sector cluster.  Neither seems to be
> > suffering from the nearly full FAT so far.
> 
> I am still scared of cluster sizes >1 — I use alot of Burke & Burke
> tools.

Since that is purely a function of rbf.mn, and I restored that to it when 
I did the original conversion to 6309 & faster code where I could, I would 
not expect that anything the Burkes wrote would interfere with that.  
However, thats just my world view, and could be wrong.  In that event, I'd 
have a tendency to point the "he did it" finger at B&B.  The multiple 
sector cluster stuff should NOT be overridden by any hardware driver.  It 
should take orders from rbf & just go do it, reporting any encountered 
errors back to rbf for it to handle if it can.

> But, I expect two 128MB drives with CoCoSDC will more than suffice. The
> only reason I filled mine up is I was copying over backed up Compact
> Flash cards from SuperIDE and my SyQuest, and most of those are
> redundant. Once I clean stuff up, I think I will be back to 50MB of
> actual “stuffâ€‌ that is mine.

For backup purposes, I would never want to be down to only one copy on a 
single media.  Currently, I occasionally do a dsave of /dd to /s1, but it 
would be nice if I could sneak in the incremental backup that backar gave 
us, but the tally method used turned into a huge disaster if and when 
anyone managed to use the 47th segment of the 48 FD.SEG's.  It wasn't well 
thought out, by me, or the backar author.  Said very simply, the bit used 
in the 48th FD.SEG, represented LSN0! So the next write, overwrote LSN0.

This is why I propose to reduce FD.OWN from integer to byte, which will 
still allow 256 unique users (even a nibble, 16 users should be a great 
plenty as I doubt that the Kalipornia hospital that ran its accounting on 
a coco2 using forth still is a coco user. The rest of us have maybe a 
dozen users maximum unless the name is Duggar, and then use the other 
remaining byte as an incremental counter to control backups.  As is, its 
so under utilized as to be someones dream of winning an emmy or ??

Unforch, the only one who replied to my question so far, apparently missed 
the concept and quoted what the bits of FD.ATT represented, and which 
would have nothing to do with reducing the potential number of owners from 
65536 to 256.  For the CoCo, running nitros9, 65535+0 owners is comical, 
but the fact that it was even allowed at design time in what, 1978? was 
and is an error, at least to me in 2015.

What I have found with grepping the src's seems to indicate that the fix 
would only involve rbf.mn itself, the dir -e command, and potentially  any 
other utils that do similar operations as the -e does to "dir". Those can 
be found and fixed as they are found.

I have not however, looked at the login command to see how it assigns the 
user number, which of course then becomes the owner. Presumably that is 
locked to the user name thru password?  Next on the agenda I guess, when 
the coffee gets at least one eye open simultaneously. :)

> Thanks.
> --
> Allen Huffman - PO Box 22031 - Clive IA 50325 - 515-999-0227 (vmail/TXT
> only) Sub-Etha Software - http://www.subethasoftware.com - Established
> 1990! Sent from my MacBook.
> 
> P.S. Since 4/15/14, I have earned OVER $600  in Amazon gift cards via
> Swagbucks! Use my link and I get credit:
> http://swagbucks.com/refer/allenhuffman


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS