[Coco] Segment List Full on backup

[Gene Heskett]

On Tuesday 27 January 2015 09:49:20 Allen Huffman did opine
And Gene did reply:
> > On Jan 27, 2015, at 5:19 AM, Gene Heskett <gheskett at wdtv.com> wrote:
> > 
> > On Tuesday 27 January 2015 00:48:27 Allen Huffman did opine
> > 
> > And Gene did reply:
> >> Er, how is it possible that backup can give a #217 error? I thought
> >> it was cloning sector by sector, so what would segment lists have
> >> to do with it?
> > 
> > You are using another fd.seg entry for every it.sas
> > sector*bytes_per_sector. An it.sas setting of 8 is only 2k.
> > 
> > There is room for only 48 entries of the 5 byte fd.seg's in the
> > fd.sector and it is not extensible.  So a file being copied will
> > fill the fd.sector at 2k+48=96 kilobytes.
> > 
> > If the disk is well used, the parts of the file may be widely
> > scattered (fragmented) on the disk.
> 
> Always useful information (like explaining the difference between #237
> memory full and #207 out of memory) -- but "backup" shouldn't be
> touching the bitmap. It should just be cloning sector to sector,
> shouldn't it?

I was not aware that we had a backup program that functioned like dd does 
on linux other than the backup that is part of the os9 cmds available.  
And it demands identically formatted disks as its safety mechanism.

Every other one (BRU, Backar etc) I have any experience with is file 
based.  Writing that file involves acquiring space from the allocation map 
to write that file to, and fd.sector fd.seg's to describe the file.  
Either one can run out of space.

Does this "backup" program you refer to actually clone one complete disk 
to another, effectively making a carbon copy of the original?  IOW, are 
you using the backup from the nitros9 cmds tree?

The os9 backup command is the only command in the box that does that. 
neither BRU nor Backar do that. But backar is what got me into trouble as 
it needs a single bit, someplace in the fd.sector to function as intended.  
But every bit is already spoken for. So I'll just drop backar until such 
time as I can come up with a fix that works.

BRU OTOH, adds some housekeeping data, and so expands the backup it makes 
slightly, but has no mechanism to do incrementals of what has been changed 
since the last backup.  We sorely need such a tool, so I still rummage 
thru the defines from time to time looking for a way to do that.  We also 
need a compression utility that could be used as a pipe member.  So our 
ability to actually make an all in one file compressed archive is so far, 
heavily crippled by the limitations of the OS itself.

So what I do, and not nearly often enough, is dsave the operating drive to 
a subdir on the second drive as I have 2 identical 1Gb scsi drives, and 
with what I have on the main drive, I could setup at least 5 such subdirs 
on the second drive if I needed multiple generations for mistake recovery.

> While I can't explain backup's behavior, I think I have an idea of what
> happened. In my most recent case, I had an MM/1 OSK disk (512-byte
> sectors, so every two LSNs on CoCo OS-9 represents one OSK sector).
> Since the EZ135 disks are 128MB (or 135MB is you use Segates "1K is
> 1000" marketting math), the LSN0 size is shown as $040000. I byte
> tapped that to $07FFFF (yeah, missing a sector) so OS-9/6809 could
> "see" the full disk. Before, backup only copied $040000 sectors (half
> the disk) because OS-9 read LSN0 and set the size to that (correct
> size if the sectors were 512 bytes).
> 
> Backup ran for hours and failed with a #217, so I wrote a BASIC09
> program to read 256 bytes at a time from source to destination. It ran
> for hours, and got to the final sector (524287 or something) and then
> issues #217.

How much data is there? That FAT/DAM limit of $FFFF, translated to bytes 
assuming a 1 sector cluster, is 134,215,680 bytes.  A full EZ135 might be 
able to exceed that but I'd have reservations it could based on the 
Seagate marketing depts legendarily wishful thinking.

FWIW, I have an LS-120 drive and a 6 pack of disks for it, but have never 
acquired the IDE interface it needs.  I should do that when it becomes 
available again.
 
> I think RBF is returning it because the sector exceeds the number of
> clusters that the DAM ($FFFF * 8 = 524,280) supports.

Now that is a possibility. It is also possible that os9 ran out of bits in 
the LSN# issued, but since that number is in LSN's, not bytes, its well 
north of 3.5Gb by then.  So I can't see that occurring.
 
> That's my current theory. The MM/1 disk wasn't maxed so even though I
> may not be able to get the very last few sectors via CoCo OS-9, I got
> all the data I was after.

Well, that is what counts at the end of the day(s).  Its a lot of spin 
time on disk heads too.  Made many hours longer in this situation by 
Alan's reversion of my 6309-ization of rbf.mn.

> 		-- A


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