Conference hydra::amiga_v1

The file system *doesn't know* if the drive is a ST506, SCSI, ESDI, or
whatever (at least it shouldn't :-)

Only the hardisk driver written for that device knows for sure!


John

    In support of .1, CBM has made it clear that FFS will support their
    A2090 controller (which makes sense, its the only hard disk controller
    they sell).  The A2090 supports up to two ST506 drives, so I deduce
    that FFS will support ST506.
        John Sauter

    FFS absolutely, positively supports C. Ltd's SCSI interface with
    no device driver modifications whatsoever.
    
    I estimate a 2-3x speedup in my drive performance.  C. Ltd has new
    drivers that will supposedly meet CBM's DMA performance of near
    500KBytes/sec.
    
    Ed.
    
    

Re: .0

The fast file system absolutely doesn't know what type of device it
is talking to.  As long as the device can read and write blocks, the
new file system is happy.

For example, the old file system, handles floppies, hard disks, and the
ASDG recoverable ram disk VD0:.  In fact, the major reason why VD0: is
three times slower than RAM: is because VD0: uses the old file system
while RAM: has its own special purpose file system.

The Fast File System is just as versatile.  You can, under 1.3, use
the fast file system on floppies.  However, the Fast File System is
not currently set up to handle removable media.  If you use the
Fast File System on you floppies and you pop a disk out and insert
a new disk, the File System will not realize that you have changed
disks.  The result will be that reads will return garbage and writes
will trash random disk blocks (they will write to the blocks that
were free on the other floppy).  Commodore has stated that under 1.4
the Fast File System will handle removable media.  Using the FFS on
floppies doesn't gain you much anyway.  The FFS speeds up drives
by a larger factor depending on how fast the drive/controller is.
On the high end for very large fast drives (over 100MB SCSI drives)
the FFS has been reported to introduce a speed up of a factor of 12.
I think that people who have tried FFS on their floppies got significantly
less than 2 times speed up.  (By the way, the Amiga's floppies are
fast for floppies.  Even under the old file system, they are faster
than an ST's, and only a hair slower than the newest MAC floppies.
The only problem with the Amiga's floppies is that with the distributed
directory information, getting a list of all the files on the floppy
is *SLOW*.)

    there was some stuff on usenet about using FFS with floppies...
    BUT....CAVEAT EMPTOR....as was stated!...
    
    I think I can wait for 1.4
    
    scott
    

Re: .5

Your right about usenet showing how to use the FFS on floppies.  The
procedure is a kludge, but works.  The three problems are:

	The physical drive shows up as two separate devices, one using
	the old file system and one using the fast file system.  (One
	of the two logical devices will claim to have a bad disk
	mounted!)

	Every time you eject a disk from the floppy drive you will have
	to do a DISKCHANGE CLI command.

	Floppies formatted with the fast file system aren't readable
	under the old file system, and the reverse.

Since Commodore says they will make the file file system the standard
for floppies under 1.4, I bet they plan on merging the old file system
and the new file system drivers.  An Amiga disk states what format it
uses (old file system are "DOS" disks, fast file system are "DOS2" disks,
I think, and Kickstart disks are "KICK").  So, if the two file systems
were combined, it would be very easy for the combined file system to be
able to handle both flavors of disks.

Re: .3

>    I estimate a 2-3x speedup in my drive performance.

Ed, did you adjust the interleave on your drive when you started using the
Fast File System?  If not, if you are willing to blow off an night with
experimentation, you might be able to get a larger speedup.

A hard drive must be tuned to the speed of the file system and the
hardware interface.  This tuning is the interleave factor.

Normally, it isn't a good idea to have logically consecutive blocks
physically consecutive on the disk.  In other words, logical block 1
on the disk should not follow immediately after logical block 0.
Instead, a more reasonable relationship might be:

			(0,0)
		(12, 6)       (1, 7)
	      (11, 12)		 (2, 1)
           (10, 5)		    (3, 8)
	      (9, 11)		  (4, 2)
		(8, 4)		(5, 9)
		    (7, 10) (6, 3)

The above is my crude attempt to depict a circular disk track with
the blocks labeled on it.  Each ordered pair represents a physical
and logical block number.  The first number is the physical block number;
notice that they start at 0, end at 12, and that physical block n+1
directly follows physical block n.  The second number is the logical
block accessed by the file system.  Like physical block numbers, logical
block numbers start at 0 and end at 12.  Unlike physical blocks,
the logical block n+1 does not directly follow logical block n on
the drive--it is two physical blocks away.  This means that the disk
has a 1:2 interleave factor.

The reason for having an interleave other  than 1:1  (an interleave
of one means that physical block number and logical block numbers are the
same) is that the computer isn't always ready to accept the next logical block
immediately after the current logical block.  The system needs a little
processing time, and interleaving the logical blocks allows for this.

If a disk isn't interleaved and the system cannot keep up with the
disk, the disk throughput goes down.  What happens is the computer reads
a block from the disk and processes it.  The computer then requests the
disk read the next block.  Unfortunately, the computer made its request
too late: the next block has already passed underneath the read head of
the disk, and the disk will have to wait for a full disk revolution
before the requested block passes under the head again.

If a disk is properly interleaved, the normal time it takes the system to
process a block is matched to the physical placement of blocks on the
disk.  When the computer reads a block, processes it, and asks for the
next block, the next block is just about to pass under the disk head.

Setting the proper interleave factor can be tricky.  If the interleave
factor is too low, the disk will have to make one complete revolution
for each block read.  If the interleave is too high, the disk will
have to wait for the proper block to pass under the head.  If the interleave
is just right, data will steam from the disk in an uninterrupted flow.

Anyway, the advent of the Fast File System means that interleave factors
must be greatly adjusted.  The typical interleave rate for a old file
system disk is probably 10-16, under the new file system, a better value
may be 2-4.  Adjusting the interleave can make a big difference.  Lets
say that your disk has 30 blocks per track, and that because of the old
file system, it needed a 1:10 interleave (these are fairly realistic
numbers!).  Under those conditions, you could only read three blocks per
revolution of the disk.  Lets say under the new file system that you can
interleave the disk at 1:2.  Now you can 15 blocks from the disk per
revolution.

When you use a SCSI disk, you typically have the disk itself worry about
the interleave.  The low level SCSI format tells the disk how it should
interleave the blocks.   (The mountlist entry can be used to have AmigaDOS
manage the interleave for non-SCSI disks.  Usually the mountlist entry
for a SCSI disk will specify an interleave of 0 because the disk is
handling the interleave.)

If you want to experiment, Fish disk 48 has a disk performance benchmark
called Diskperf.  This benchmark prints all sorts of interesting information
about the speed of the disk (it was also the benchmark used in Amazing
Computing's review of hard disks last year).  You could reformat your
disk trying different interleaves to see what gives you the best performance.

I don't know how to specify the interleave with a C Ltd disk subsystem.
You could look at the DEVS:Mountlist entry for your disk to see if AmigaDOS
or the SCSI disk itself is handling the interleave.  If the disk itself
is handling the interleave (the most probable case), you will need to
find out how to specify to the low level format utility from C Ltd
the interleave for the disk.  Since C Ltd does sale their controller without
a disk, they must have someway of handling an arbitrary drive.  After
figuring out how to specify the interleave:

	Perform a low level format of the disk.

	Partition disk disk into some small partition:  a 5 or 10 Meg
	partition is good enough to experiment with.

	Mount the partition.

	Format using AmigaDOS the partition.

	CD to the drive, and run Diskperf.

The reason for making a small partition and only formatting using AmigaDOS
that partition is that AmigaDOS takes *forever* to format a drive.  Since
you are only experimenting, it is Ok to only have a 5 Meg partition on a
20 Meg drive.

I would try interleaves of:

	1	(If your drive/interface is slow enough this might work)
	2	(Most probable "good" interleave)
	4 and so on.

You will know when you have got a good interleave when the drive suddenly
takes a major performance increase.  Higher interleaves will then slowly
eat away at that increase in performance.

By the way, it would be interesting to keep the performance data Diskperf
produces for each level of interleave.  You can do this by redirecting
the output of Diskperf to a file (NOT on the disk you are testing--it
would alter the results!) or if you run SNIP, you could cut an paste
the data into an editor window.

>  C. Ltd has new
>    drivers that will supposedly meet CBM's DMA performance of near
>    500KBytes/sec.

They probably aren't using normal drives if they are getting that type
of performance.  The only drives that fast are the big (over 100 Meg)
super fast, super expensive drives.  For a fast consumer drive a speed
of 200 Kbytes/sec is pretty good.

    
    Thanks for the info Randy.  I do understand interleave, but
    was stymied by the '0' entry in my Mountlist.  I have an ST277N
    intelligent SCSI drive, so, you say, the SCSI.device driver will
    probably need to be modified.  I'm still unclear as to how C Ltd's
    SCSI.device file can be optimized for your particular drive.  They
    only provide one version with their controller.
    
    I just spoke with Ed Lippert yesterday. C Ltd will be posting SCSIDos
    3.3 on their BBS on the same day that 1.3 is officially released.
    (They didn't need any more beta testers :^<).
    
    Ed clarified a few things for me.  For one, an ST506 drive with
    an OMTI controller will actually be quite a bit faster than an
    embedded SCSI drive.  Apparently this is credited to an 8K buffer
    on the OMTI controller.  So, an older ST251 drive could be quite
    a steal.
    
    Ed felt that I should see 200-250KBytes/sec.  Not up to the fastest
    AT drives, but still better than 5x faster than under OldFileSystem.
    
      //
    \X/  Ed.

Re: .8

The SCSI driver does not have to be modified to work with a different
interleave.

In the SCSI protocol, the driver asks the disk for a logical block by
number.  The intelligence in the drive then determines which head, track,
and physical block to read.  So, the software driver and the hardware
host interface have no idea what the physical geometry of the drive is.
For a SCSI device, the AmigaDOS mountlist can claim ANY geometry as
long as the number of heads times the number of tracks times the number
of blocks per track multiplies to the right number of blocks for the
drive.  So heads=1, tracks=1, blocks=10000 is equivalent to heads=10,
tracks=10, blocks=100 for a SCSI drive.

The interleave of the SCSI drive is controlled its low-level (SCSI)
format.  The protocol is that the host adapter sends a command to the
drive "Format your self with the following interleave."  The intelligence
in the drive then handles the rest of the operation.  While the drive is
formatting itself, the host system software, the host adapter, and the
SCSI bus is not being used at all!  (Well, if another drive is on the
SCSI bus, all they might be talking to it.)

In fact, byte four of the SCSI format command is the parameter used to
tell the drive what interleave to use (the bytes in the command are
numbered starting at zero by the way).

So the question becomes: Does the C Ltd format utility have any sort of
parameter file, or does it just have this byte hard coded in the utility?
The Pacific Peripherals' low level formatting utility has a parameter file
that allows you to edit the SCSI commands used to format the drive, park
the heads, do a bad block scan, set the sector size, and similar stuff.

>    Ed felt that I should see 200-250KBytes/sec.  Not up to the fastest
>    AT drives, but still better than 5x faster than under OldFileSystem.

I have seen a number of sources claim that 200Kbytes/sec is pretty much
tops for a AT with ST-506 drives.  To break the 200KBytes/sec barrier
requires using EDSI drives.  (Beware disk performance for clones: they
usually quote numbers with units of K BITS per second.)  With the Fast
File System, the Amiga ends up with hard disk performance equivalent
to Clones, Macs, etc.

    Actually, the saga of my hard drive is a bit complicated.  The version
    of software that came with my C Ltd. controller was actually written
    for non-SCSI drives.  There were several good utilities for formatting
    the drive; interleave was an option.
    
    However, when I received my Seagate ST277N, we were totally unable
    to deep format it.  We ended up calling C Ltd and downloading a
    new file called 'Seagatefmt'.  The only argument that this command
    will accept is unit number.  So, I assume that the software is asking
    the drive to handle whatever it thinks is the proper interleave.
    
    There are several 'quickformat' utilities, but these just ask for
    the number of cylinders etc and partition info.  So far, I haven't
    seen a way to do this, but I really didn't bring it up in conversation
    with C Ltd.
    
    C Ltd is really helpful over the phone, but their documentation
    is hideous.  I'm not extremely clever, nor am I extremely stupid,
    but I was totally lost as I read their disk-based documentation.
    
    Anyway, I plan to get to the bottom of this one way or another.
    The drive is plenty fast, but of course I want all it's capable
    of.
    
    Thanks for your inputs.
    
    Ed.
    
    

    I just installed FFS on my third partition (dh2:).  I have two
    partitions of equal size.  DH1: and DH2: are each 5.1M.  DH1: is
    the old file system.
    
    Last night after I formated DH1:, I copied a bunch of text files
    to it.  Today, I formatted DH2:, and did the following:
    
    	Copy dh1: to dh2: all
    	Info
    
    and the output was
    Mounted disks:
    Unit Size     Used     Free Full Errs     Status     Name
    DH2: 5.1M     4201     5997  41%   0    Read/Write   SupraDrive2
    DH1: 5.1M     4371     5827  43%   0    Read/Write   SupraDrive1
    
    I left out the other disks.  Both of these partitions have the same
    files, but the new FFS seems to hold more information.  As far as
    I know, there is no fragmentation on DH1: or DH2: because I did
    not remove or rewrite any files.
    
    	--Mike

    I believe the FFS uses all 512 bytes in data blocks to hold data,
    instead of putting some overhead in each data block.  The overhead
    information is now concentrated into other blocks.  The result should
    be a more efficient use of disk space, in almost all cases.
        John Sauter

    re:.-2
    
    How did you get ahold of FFS. Does everybody have WB 1.3 except
    me. I thought this was supposed to come out some time ago, but I
    haven't seen it anywhere.
    
    What's the scoop?
    
    Chris

    It's still not released, Chris.  Registered developers, dealers,
    and all Amiga owners except yourself have a copy. :^)
    
    Late July release is the latest RSN date.
    
    Ed.

    I'm an Amiga owner - I bought mine last winter - but I don't have
    any 1.3 software yet.  How do I get it???
    
    Rich.
    

    
    You can obtain the new Preferences and printer.device, plus a dozen or
    so new printer drivers by purchasing ProWrite 2.0, Shakespeare, or
    Excellence. These vendors were allowed to release these new system
    files by special arrangement with Commodore.
    
    To legally get FFS and other goodies, you'll have to wait for the
    official release, unless you obtain a bootleg Gamma version, like
    I did from a friend of a friend of a friend.
    
    I'm darned if I know whats taking so long, since my pre-release
    is rock solid.  At AmiExpo, developers were given an Omega version
    and told that release would be 'next month'.  Wags commented that
    they've been told 'next month' for 6 months now.

    maybe CBM is trying to make sure they have enough copies ready
    to satisfy the anticipated demand for it.  And they didn't want
    to start making tons of copies until they were sure that it was
    ready.
    
    Naw... they are probably playing for time.  Instead of trying
    to convince dealers to sell a very low profit item (1.3), they
    are trying to create a strong user demand for it.  That way,
    the dealers will want to sell it because they can make a profit
    on the volume of sales.
    
    -dave
    p.s. surely there must be better conspiracy theories floating around
    .... how about: they can't get enough bulk disks, or the disks
    aren't cheap enough, to ship it?  :-)