[Coco] Large file deletion fails on NitrOS9/6309

[richec]

On Thu, 28 May 2020 20:03:27 -0600
"L. Curtis Boyle" <curtisboyle at sasktel.net> wrote:

> On May 28, 2020, at 7:50 PM, Gene Heskett <gheskett at shentel.net>
> wrote:
> >   
> >>>>   
> > One other thing I should point out as this conversation is
> > refreshing my memory a bit, is the segment allocation size (DD.SAS)
> > in the disk descriptor, which may, for old installs, still be set
> > at 8 which does allow all 48 segment 5 byte entries, 24 bits for
> > offset start, and 16 bits for length, to be used.  There is no
> > recovery for that, never has been, probably never will be.  
> 
> In EOU, we left SAS as 8, but on the hard drives, its set to $80. We
> hit problems with it too low at work all the time, since we regularly
> used multi-megabyte files. (Actually, at work, we use $FF).
> 
> > 
> > I submitted a patch that expands that DD.SAS to $20 (32 decimal)
> > sectors as insurance of never hitting the end of that 48 segments
> > because if you do, its blowup time. Use dmode to check that, and or
> > fix it if yours hasn't been corrected to $20. Do it NOW. The only
> > side effect will be the inability to use the last 31 sectors of a
> > floppy.
> > 
> > But what size is that set to in the toolshed disk code?  If it is
> > still using 8, there quite likely is your problem. When set at $20,
> > but the file does not use that $20, rbf gives back at the end of
> > the transaction, all sectors that are not actually used. But you
> > cannot play mix-n-match with the DD.SAS, it must be consistent
> > across all software that can access that storage media.  And of
> > course if toolshed is cluster size sensitive, that must also match
> > what the disk (or file) is formatted to. I don't know that toolshed
> > is cluster size sensitive.  Its possible it is not. I've never
> > kicked its tires as its newer than when I worked on rbf, and after
> > a pulmonary embolism several years ago at 79 yo, I am not capable
> > of doing it today at 85 yo. Those things, with a 98+% fatal rate,
> > are hard on the IQ.  There are folks here who could, but I'm sadly
> > no longer in that group.  Now its up to the newer generaion of
> > coco/nitros9 fans here to find this one and fix it.
> > 
> > Obviously toolshed's version of dd.sas should be checked, and if
> > not fixable, disabled from ever working with os9 formatted media.
> > Or disabled if cluster sizes don't match.  Thats 2 conditions it
> > should check for.
> > […]  
> 
> I honestly don’t think the SAS setting is relevant in Toolshed. In
> RBF, SAS is used as the minimum number of clusters/sectors that it
> looks for to be empty and contiguous, but it will fall through to
> using less if that is all that it can find. SAS is a tool to reduce
> fragmentation (another way, if you know what size the file you are
> creating will end up being, is to pre-extend the file to it’s full
> size first, then fill the file in with data). Toolshed is definitely
> assigning more than $800 sectors/clusters per segment, and that is
> overflowing RBF’s internal buffer for handling the bitmaps. (These
> files can be fixed after the fact on the Coco side, however - a quick
> utility to expand the single segment entry to as many entries as
> needed, and making each entry’s start offset picking up where the
> previous left off, will fix such files to be compatible with RBF (as
> long as you stay within the 48 segment/24 MB limit). Bill Nobel will
> be looking into seeing if we can “fix” RBF to work with a partial
> cache of a large file's BAM, so that it can handle one sector’s worth
> at a time. We have to be careful with disk locks, though, so that it
> makes sure that it has blocked off access to ALL of those sectors
> needed, so that another process can’t come in and change things
> before the original process deleting the file knows what is happening.
> 
> 
> > 
> > Cheers, Gene Heskett
> > --   
> 
> 

OK... Ignorance on... what is a BAM? TIA