Xref: utzoo comp.sys.amiga:35437 comp.sys.amiga.tech:5668
Path: utzoo!attcan!ncrcan!ziebmef!mcp
From: mcp@ziebmef.uucp (Marc Plumb)
Newsgroups: comp.sys.amiga,comp.sys.amiga.tech
Subject: Re: New 10meg 3.5" drives
Message-ID: <1989Jun13.213333.5088@ziebmef.uucp>
Date: 14 Jun 89 01:33:31 GMT
References: <3131@ncsuvx.ncsu.edu> <19334@cup.portal.com>
Reply-To: mcp@ziebmef.UUCP (Colin Plumb)
Distribution: usa
Organization: Ziebmef Public Access Unix, Toronto, Ontario
Lines: 50

In article <19334@cup.portal.com> FelineGrace@cup.portal.com (Dana B Bourgeois) writes:
>Wouldn't this unit make a good candidate for
>that new File System being designed by (Oh lord, I need virtual memory
>so I can store everyone's name in it!), uh, was it devon?  C'mon,
>surely you remember all the talk about the File System that would write
>whole tracks instead of sectors.  Bet more than 11 Meg could be put
>onto each disk.

I think it was me (name: Colin), and I'm working on it.. slowly.

If something is SCSI, then it's not amenable to the techniques
I use, which know that the device driver copies data into buffers a
track at a time.  Since the buffering algorithm is hidden on the other
end of the SCSI bus, I have to live with whatever the firmware authors
designed.

All the expanded capacity comes from deleting the 6-word headers on each
block (okay, so I have 6 *bytes* per *track*, sue me), which the FFS does,
and using the header label area (27.5K bonus).  I also reduce the size
of file headers by a factor of 10, so you can fit 40,000 or so empty files
with single-letter names and no comments on a floppy, or waste less than
a K on administrivia for a single floppy-sized file.  On a SCSI device,
I'd only gain the last point over FFS.

Also, a lot of the tradeoffs are based on the 27K/sec read speed of the
hardware relative to the cost of blitting a track's worth of data around.
What do you want to bet the 10 Meg floppies are faster, changing all
the tradeoffs?  I do a *lot* of speculative data copying, knowing that
if it saves me a fraction of a seek (average) later, it's worth it.
Not true for disks with faster seeks and more data to copy around...

And, the numbers of bits I have assigned to some things become inadequate
around 1.5 Meg.  Since floppies are always full, I tried hard to save space.
For larger drives, my administrivia would dramatically increase in
size.

I have a few ideas for a hard drive file system - performance goals include
1MB/sec DiskPerf on a 90% full volume and crashproofness for the file system.
(Question: two adjacent sectors is all a modern drive will usually trash in
a glitch, but head crashes and things can take out whole surfaces or
cylinders.  Being robust requires writing two copies of all vital information
sufficiently far apart that they will not both be erased by a single
glitch, so greater resistance can be purchased at the price of more seeks.
How big an error would people like to be able to cope with?  The ultimate
is twin disks, but you can come close on one.)

But that's for some *year* or other...  If anyone gets impatient, please
write your own!
-- 
	-Colin Plumb