Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!pro-houston.cts.com!dkl
From: dkl@pro-houston.cts.com (David Karl Leikam)
Newsgroups: comp.sys.apple
Subject: Re: Hard Disk Construction
Message-ID: <3008.cortland.info-apple@pro-houston>
Date: 22 Nov 89 17:36:27 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 33


In CS-ID: #3008.cortland/info-apple@pro-houston mattd@apple.com (Matt deatherage) writes, 

> In article <7484.infoapple.net@pro-generic> ericmcg@pro-generic.cts.com (Eric Mcgillicuddy) writes:
>> 
>> One method might be to increase the block size to 1k bytes (4 sectors) since
>> Prodos is a block structured OS (right jargon?) this should double the
>> effective size to 64Meg. The volume bit map just tracks blocks, not sectors, I
>> think. This will increase wastage if you have a lot of small files, but you
>> did ask for ANY solution.
> 
> Yes, but this would also break any application that uses READ_BLOCK or
> WRITE_BLOCK, as well as requiring changes to the basic ProDOS command
> structure (since a file with the same number of blocks is now capable of
> having more data in it).  In other words, it would probably break about 55%
> of the existing ProDOS 8 programs available today.

   Waitasec. Guys, stop mme when I'm wrong, but _this doesn't gain you much_.
Files still get allocated in blocks, and a 1 block file is still a 1 block
file, regardless of block size. If a file doesn't need a whole block, too bad.
This wastage is tolerable at the current blocksize, but not at the expanded
size.  About the only way to get around that wastage is to build your own
translator, so to speak, to rationalize the files on the fly while writing to
the new disk structure - a thing I suspect you'd have to do anyway. 

  Otherwise, your seedling files are simply gonna  waste 4 times as much room,
and only quite large files are going to realize much benefit from this
approach, in terms of saved space. Not so?

> 
UUCP: crash!pro-houston!dkl
ARPA: crash!pro-houston!dkl@nosc.mil
INET: dkl@pro-houston.cts.com