Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!killer!texbell!sugar!uunet!mcvax!unido!fauern!faui44!mlelstv
From: mlelstv@faui44.informatik.uni-erlangen.de (Michael van Elst )
Newsgroups: comp.sys.amiga.tech
Subject: Re: Upgrading to 1.3 (was Re: CBM's "blessing")
Message-ID: <663@faui44.informatik.uni-erlangen.de>
Date: 10 Oct 88 11:53:53 GMT
References: <8810052225.AA04169@cory.Berkeley.EDU>
Reply-To: mlelstv@faui44.UUCP (Michael van Elst (kdebugger))
Organization: CSD., University of Erlangen, W - Germany
Lines: 25

In article <8810052225.AA04169@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes:
>...  Frankly, *nobody* should use the FFS for floppies until
>it's supported officially (i.e., they use that nice 16 byte tag field for
>a checksum).  Currently, using the FFS on floppies is dangerous because
>disk errors that would have otherwised been caught might be missed due to the
>lack of a checksum in data blocks.

This is not completly true. Disks have checksums for their data blocks
besides the DOS-checksums. This errorchecking is not very well but it
is there, and I did not find any error on my disks that was not caught
be this (low-level) checksum.
For a complete (but very brief) description of the disk format, you
may consult the RKM:Exec.

I agree with you that FFS should not be used for floppies. Just because
it is rather complicated.
BTW, I have tried FFS on disks. There is speedup (50 percent average)
in directory scanning and no speedup in data transfer (actually 2-3 percent).
The filesystem is NOT a bottleneck on floppies because of the smaller
date transfer rate. (about 20 kbytes/sec on trackdisk reads)
And if you have 880k on your disk you won't insist on 10 percent larger
capacity.
				Michael van Elst

E-mail: UUCP: ...uunet!unido!fauern!faui44!mlelstv