[Coco] CoCoSDC performance issue - can someone try this from OS-9?

[Richard E Crislip]

On Sun, 1 Feb 2015 00:37:20 -0800
"K. Pruitt" <pruittk at roadrunner.com> wrote:

> 
> ----- Original Message ----- 
> From: "Nick Marentes" <nickma2 at optusnet.com.au>
> To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
> Sent: Sunday, February 01, 2015 12:29 AM
> Subject: Re: [Coco] CoCoSDC performance issue - can someone try this
> from OS-9?
> 
> 
> > On 1/02/2015 5:41 PM, Allen Huffman wrote:
> >>> On Feb 1, 2015, at 1:34 AM, Nick Marentes
> >>> <nickma2 at optusnet.com.au> wrote:
> >>>
> >>> The SDC reads a FAT32 file system on the SD card. I wonder if
> >>> this is creating the problem with a loaded SD card?
> >> That was what I originally wondered about — if the huge 128MB
> >> files were fragmented, causing extra seeking around. I expect the
> >> low-level FAT firmware isn’t as elegant and speedy as what runs on
> >> our desktops.
> >>
> >> When I copied all my files off, then reformatted and moved them
> >> back, I would expect zero fragmentation of my .DSK files. I have
> >> 1.9GB out of 8GB available, so that may not have anything to do
> >> with it.
> >>
> >> At this point, I do not think it is CoCoSDC. I think it was me not 
> >> realizing my 128MB drive only had 1-2MB of free space, so RBF is
> >> probably having to climb through a bunch of stuff to find spots
> >> for even tiny files. Maybe they are only at the end, and it has to
> >> read in 64K of bitmap every time looking for the empty bits at the
> >> end of the disk.
> >>
> >> Nick: There is up to 64K set aside as a bitmap marking which
> >> sectors are free. Each bit represents a sector, 0=free/1=used.
> >> Thus, if I want to write a tiny file that takes 256 bytes, it
> >> opens the bit map and has to parse through it looking for bytes
> >> with 0s in it to use.
> >>
> >> — A
> >>
> >
> > You realize that defrag does little speed-wise on any memory based
> > drive?
> >
> > There is no head seek on these, they just access the next block
> > instantly just like normal memory.
> >
> > Nick
> >
> >
> 
> You're right, but he's trying to make a larger contiguous block of
> space on the drive using defrag.  That should work as expected.
> 
> 
> 

Ahhh... doesn't that destroy the drive? Or are you using the DSave or
some method similar to that?