Subject: REVIEW: Ami-File-Safe (AFS) filesystem
From: [email-masked] (Mat Bettinson)
Date: 28 Jun 1995 18:53:03 GMT
Newsgroups: comp.sys.amiga.reviews

PRODUCT NAME

	Ami-File-Safe (AFS) replacement file system for all Amigas.

BRIEF DESCRIPTION

	AFS has been developed from the shareware file system called
Professional File System (PFS). Forth Level Developments have taken on the
project in conjunction with the original author, Michiel Pelt. AFS is
designed to replace the Fast File System on Hard and Floppy disks.

AUTHOR/COMPANY INFORMATION

	Name:		Forth Level Developments
	Address:	31 Ashley Hill, Montpelier
			Bristol BS6 5JA
			United Kingdom

	Telephone:	+44(0)117-985-4455
	Fax:		+44(0)117-955-9157

	E-mail:		[email-masked]

	English only, AFAIK.

LIST PRICE

	#59.36 Pounds Sterling. (~$94 US ?)
	VAT payable within UK at 17.5% I.E. #69.75

SPECIAL HARDWARE AND SOFTWARE REQUIREMENTS

	HARDWARE

		None. 1.3 owners, you should get a new Kickstart before this!

	SOFTWARE

		For HD installation, some decent Prep software. It's
		possible with HDToolbox but I recommend RD Prep.

COPY PROTECTION

	Individually serialized. A deal has been struck with a global
security company to track down pirates, allegedly. I expect the price point
is high to compensate for the high levels of piracy this is likely to
attract. :-/ As usual it's the decent users that pay for the scum bags.

MACHINES USED FOR TESTING

	A4000/40 + Cyberstorm 060 + Cybervision. 14MB RAM. 512MB IDE Connor
	HD.  Also used with stock 3640.

	A3000 + GVP Spectrum + GVP IO Expander, 540MB SCSI Connor, 105MB
	Quantum. OS 3.1 Softkicked.

	A1200 stock and with Apollo 1220 28Mhz '020 board + 4MB Fast Ram.
	120MB Seacrate from A4000.

INSTALLATION

	Via the Commodore Installer, it's relatively painless. Not really
much to it. The entire biz is really a 38K file that sits in L: There's a
smaller floppy version and the 68020 optimized versions of each is provided.
Selection of CPU type is manual in the Installer. To install on a floppy,
it's just a question of mounting from either a mountlist or a separate
mountfile in DOS-Drivers etc. Referring to the floppy as AF1: or something
will treat it as an AFS disk. Naturally only one is possible. On all
machines I had the floppies mounted as DFx:, PCx: and AFx: with no problems.

	For hard drives, it's a little bit more involved obviously. Firstly,
to affect a conversion to AFS, you will need to shovel the contents entirely
off the disk. Hopefully Holger Kruse will be good enough to add AFS support
in ReOrg at some stage and add a conversion to AFS from OFS/FFS. For now,
copy everything off the partition/s. Then hitting the prep software is the
go. In RD Prep (which I used and recommend) I just plugged in the file
system in the Complex Mode file system page. Changing the DOS type to 'AFS1'
in Hex and making the source file the relevant 'HardDiskAFS'. Back to the
partition page, I changed the partition file system to AFS, upped the
buffers to around 200 (which AFS needs as it has a cache solution built-in.
This is the value of the cache) and then moved back to the main page and
saved my RDB out. Cool. Reboot or a dismount and remount from an RD-Prep
saved mountlist, and a quick reformat later, bang. Up pops an AFS requester.
We have an AFS partition. Painless.

THE REVIEW

	I was dead keen to have a perv at AFS. Having played with PFS
before, I saw it had great potential though a shame that it just wasn't up
to scratch and dead buggy. Checking out AFS, it offered no problems
installing onto a reasonably large partition. I'd archived up this partition
with LZX to shovel it off. With a Cyberstorm I did it that way mainly
because I can. :-) After no time it was done. Installed, reformatted and
extracted the mother or all archives back to the newly created AFS
partition. Ho Ho Ho. Extracting back to that partition now it was AFS was
unbelievably quick though I really couldn't tell HOW quick. On this platform
I left it be for some time. Ran all my software as before. Didn't notice any
problems or the speed boost since I still wasn't used to the Cyberstorm.
It's time to install on my 3000 at home.

	It was here that I noticed how much faster it really was. Directory
scans blow FFS-DC away. Writing is so much quicker it's scary. Installing to
floppy, I did some basic benchmarks and had to re-do them since I didn't
believe them at first. Since I run a BBS and toss a lot of Usenet and Fido
with a tosser called Mail Manager, I decided to give it a whirl on that. Oh
dear. It broke it badly.  Mail Manager was performing useless scans left
right and center. Fault reported to the author of MM and to Forth Level.
Within days I had a fix in MM and a fix in AFS (though it wasn't really a
bug). Tried with Mail Manager again. My *GOD* it was amazing! Tossing sped
up from around 500 messages per minute up to 1200 or so! Also less drive
thrashing and the works. Hell, even more disk space free.  This is too good
to be true. There has to be a catch. There's no undelete at this time. Nor a
salvage program. This must be a serious catch. I can't believe I'm one of
the few to have discovered this product. So... It was time to see exactly
how Safe Ami-File-Safe is.

	Next couple of days I did things that would make your eyes water.
Reset when writing large files time and time again. Waited until AFS was
flushing the write retention cache or writing the BAM/FAT back and literally
powered down.  Each time I thought, that will shaft it. There's no way it's
gonna survive that.  Since it never invalidates, I wondered how it would
handle a corrupted disk.  However, I never found it. The blasted thing never
corrupted! Sheesh... Taking it on as a challenge I started doing hideous
things. Pulling the SCSI cable out during a write. You name it, I did it.
(On a crap Quantum 105 just to be on the safe side) and ... Zip. There's no
doubt about it. This is one *SAFE* mother this Ami-Safe-File system. Still
could do with that undelete too though.

	The fact that AFS uses files across blocks and not 1 block minimum
and leaving the last block partially empty like FFS means it is much more
efficient on disk space. However, the disk space figures that WB provides
are often bogus. Also things report that the capacity is lower to start
with. This is because it's allocated some space for the dir structure etc to
start with. At the end of the day, it fits more on than an FFS disk by a
long ways. The Info command gets it right though.

	Even while some program is heavily accessing a partition, if you
were to open that drive on the WB or some other parallel access, there's no
thrashing. Obviously the speed is much lower than if you can entire control
over that device but overall it's very apparent that the sum of the
transfer/performance of each task is pretty much the full rate that the
device is capable of. AFS claims this in the manual but to see it doing it
is a pleasure I only dreamed of. Obviously with FFS, there's some many
hideous seeks like after every block or so, that each task trying to access
the same partition slows to a stand still. Most people will remember this
phenomenon from attempting to boot when a partition is unvalidated. Another
vice AFS doesn't have.

	One thing of note. With A3000's, the bare minimum of routines in the
Boot ROMS (the ones you'll have if you're soft kicking) aren't enough to run
AFS. I solved this by mounting my AFS partitions in my start-up sequence
rather than auto-mount them. No real sweat, though Forth Level say they have
found a way to make it work in the RDBs of soft kicked 3000s. In the next
version, I presume.

	There's no ReOrg for AFS either. Having said that, disk
fragmentation is really an OFS/FFS phenomenon. The manual actually claims
that AFS will attempt to defragment fragmented files by itself. I'd like to
know if that's true. Hard to know for sure.

	Did I mention how fast dir scans are? Oh I did. Mmmm... Better put
up or shut up then I guess. Time for some benches.

BENCHMARKS

<Cut to the first tests for brevity. All tests were indicated the same level
of improvements>

MKSoft DiskSpeed 4.2  Copyright  1989-92 MKSoft Development
------------------------------------------------------------
CPU: 68030  AmigaOS Version: 40.70  Normal Video DMA
Device:  TESTFFS:    Buffers: 200
Comments: FFS Partition

CPU Speed Rating: 1375

Testing directory manipulation speed.
File Create:           55 files/sec  |  CPU Available: 62%
File Open:            294 files/sec  |  CPU Available: 3%
Directory Scan:       409 files/sec  |  CPU Available: 11%
File Delete:          454 files/sec  |  CPU Available: 5%

Seek/Read:            878 seeks/sec  |  CPU Available: 7%

Testing with a 32768 byte, MEMF_FAST, LONG-aligned buffer.
Create file:       227104 bytes/sec  |  CPU Available: 24%
Write to file:      51949 bytes/sec  |  CPU Available: 69%
Read from file:    244537 bytes/sec  |  CPU Available: 19%

Testing with a 65536 byte, MEMF_FAST, LONG-aligned buffer.
Create file:       222155 bytes/sec  |  CPU Available: 26%
Write to file:      51895 bytes/sec  |  CPU Available: 69%
Read from file:    236386 bytes/sec  |  CPU Available: 20%

Testing with a 131072 byte, MEMF_FAST, LONG-aligned buffer.
Create file:       238601 bytes/sec  |  CPU Available: 22%
Write to file:      49742 bytes/sec  |  CPU Available: 70%
Read from file:    244537 bytes/sec  |  CPU Available: 20%

Testing with a 262144 byte, MEMF_FAST, LONG-aligned buffer.
Create file:       235106 bytes/sec  |  CPU Available: 21%
Write to file:      50219 bytes/sec  |  CPU Available: 70%
Read from file:    238312 bytes/sec  |  CPU Available: 20%

Average CPU Available: 32%  |  CPU Availability index: 440

MKSoft DiskSpeed 4.2  Copyright  1989-92 MKSoft Development
------------------------------------------------------------
CPU: 68030  AmigaOS Version: 40.70  Normal Video DMA
Device:  TESTAFS:    Buffers: 200
Comments: AFS Partition

CPU Speed Rating: 1375

Testing directory manipulation speed.
File Create:          169 files/sec  |  CPU Available: 2%
File Open:            292 files/sec  |  CPU Available: 0%
Directory Scan:      1780 files/sec  |  CPU Available: 0%
File Delete:          285 files/sec  |  CPU Available: 0%

Seek/Read:             96 seeks/sec  |  CPU Available: 73%

Testing with a 32768 byte, MEMF_FAST, LONG-aligned buffer.
Create file:      1073152 bytes/sec  |  CPU Available: 1%
Write to file:    1150976 bytes/sec  |  CPU Available: 2%
Read from file:   1363968 bytes/sec  |  CPU Available: 8%

Testing with a 65536 byte, MEMF_FAST, LONG-aligned buffer.
Create file:      1116720 bytes/sec  |  CPU Available: 1%
Write to file:    1209392 bytes/sec  |  CPU Available: 1%
Read from file:   1372823 bytes/sec  |  CPU Available: 12%

Testing with a 131072 byte, MEMF_FAST, LONG-aligned buffer.
Create file:      1146880 bytes/sec  |  CPU Available: 1%
Write to file:    1245184 bytes/sec  |  CPU Available: 0%
Read from file:   1343488 bytes/sec  |  CPU Available: 16%

Testing with a 262144 byte, MEMF_FAST, LONG-aligned buffer.
Create file:       973306 bytes/sec  |  CPU Available: 1%
Write to file:    1259066 bytes/sec  |  CPU Available: 0%
Read from file:   1376256 bytes/sec  |  CPU Available: 16%

Average CPU Available: 8%  |  CPU Availability index: 110

	As you can see. Individual block seeking is slower. It also uses a
lot more CPU time than FFS (caches?) but the speed is radically faster.
Another note is that on heavily fragmented FFS partitions, file handling is
markedly worse. AFS seems to stay the same. Maybe it's true it doesn't
fragment much?

	I left the floppy benches at a mates place. They were really
impressive. I'd delay this review if they were essential but since most
people considering forking 70 quid for this product would be looking at HDs,
just take it as red that floppy performance is out of this world under AFS.
I'll post them in comp.sys.amiga.misc or something later on.

COMPATIBILITY

	Worked in all machines tested just fine though not possible to
install in the RDB of a soft kicked 3000. All software worked fine.
EVERYTHING ran on the AFS partitions as normal. I had a problem with a Beta
version of Mail Manager that I run. Turns out it was a slightly unexpected
action of AFS at fault. The author of Mail Manager fixed his program and
Forth Level Developments also made a change to AFS to cure that instantly.
Since this is the most complex type of DOS activity around (Mail tossing to
custom message bases with Async IO) I'm confident that it's pretty much 100%
compatible with everything else now though... There may be other lingering
problems. Forth Level are quick to sort them out in any event.

DOCUMENTATION

	Mine was a laser printed pre-production run but that will only affect
the aesthetics. Basically the manual itself is extremely basic. Very short
and to the point, it's not too bad. However I would have preferred some more
in depth information on AFS. Technical reference or something. It explains
installation and some other aspects OK but it could be better. For the
money, a poor effort.

LIKES

	If I sounds like I've raved, then I've communicated successfully
exactly how groovy this product is. It makes as much difference as adding
some fast Zorro III SCSI controller from hell. It's more efficient on disk
space. On large drives, it may even pay for itself that way alone. It also
never invalidates or thrashes with parallel access. Brilliant if, like me,
you use your Amigas multi-tasking capability to the max.

DISLIKES AND SUGGESTIONS

	No undelete at this time. Coming but it ain't here now. The manual
could be better. Otherwise, not much.

COMPARISON TO OTHER SIMILAR PRODUCTS

	There's only really its predecessor PFS to compare with. There's no
comparison, PFS in the freely distributable guise is limited to 32MB and I
encountered many bugs with it. AFS is really in a class of its own.

BUGS

	The only bug I had was fixed instantly, and it's debatable that it
was even a bug. Updating the date on files before closing them caused
problems but that was moved back to the way that FFS deals with it for
compatibility.

VENDOR SUPPORT

	Forth Level are about as helpful a bunch of characters as you could
hope to deal with. Solving problems over the phone. Calling back. Sending new
versions. Being contactable via E-Mail etc, I wish all vendors were this
good.

WARRANTY

	Mmmm... Updates to 2.1 are free and possibly beyond. Otherwise, I
doubt they'll accept responsibility if AFS eats your drives however unlikely
that is.

CONCLUSIONS

	The claim on the box/manual that AFS is the new default filing system
for the Amiga would be brash if it wasn't likely to be true.

	However, I do think it's priced a bit high. OK granted it offers
increases in performance that are unheard of without beefing up your CPU and
controllers, etc., but I think they would get AFS into common public use
better by using a lower price point and shifting more copies.

	So... At this price, if you're in the market for a faster controller,
drive or even some sort of cache, forget it. Buy AFS. It's seriously groovy
and likely to be a lot cheaper.

	BTW when installing AFS for the first time, you must listen to Pink
Floyd's 'Run Like Hell' for the full effect. :-)

	I think Amiga Technologies should be talking to Forth Level about
this one.  Now.

COPYRIGHT NOTICE

	This review is Copyright 1995 by Mat Bettinson and freely
distributable as long as you don't use it commercially, that is, print it in
a commercial magazine. It may *not* be printed in any UK based Amiga
computing magazine.

You can reach me at:

[email-masked]
2:254/205.0@fidonet
39:139/5.0@amiganet

Catcha,
     _ ___
/\/\(-) |  @ darkside.demon.co.uk

---

   Daniel Barrett, Moderator, comp.sys.amiga.reviews
   Send reviews to:	[email-masked]
   Request information:	[email-masked]
   Moderator mail:	[email-masked]
   Anonymous ftp site:  math.uh.edu, in /pub/Amiga/comp.sys.amiga.reviews