Contents | < Browse | Browse >

===========================================================================
                            AFS Review Fallout
===========================================================================

[Generally, people are happy enough to let me do my reviews.  But the
review of Ami-File Safe did not go unnoticed...-Jason]

From Osma Ahvenlampi, editor of the Amiga Report Tech Journal:

The speed tests you made were hardly fair, giving AFS 7 times as much RAM
buffers as FFS.

Admittedly, FFS does not use them for much, but still, you effectively were
using a disk cache on AFS and none on FFS.  I've found the results to be
completely different when both are cached, or AFS has only 30-40 buffers
like FFS.

Also, DiskSpeed didn't show the CPU usage in your tests.  If it had, you
would have found that FFS took 10-30% of CPU, depending on buffer size,
while AFS took 100%.

From: John Larkin  <lurker@m-net.arbornet.org>

Hi, 

I just read your review of AFS and there's one very important point you
over-looked; reliability.

I'm not a programmer, but I do understand, basically, the way that AFS
works.  AFS tries to be as safe as possible by writing the file to disk,
then creating a new copy of the directory and when everything has been
successfully written, it updates the pointers from the old dir to the new
dir.  This is the point where the entire thing is vulnerable.

If something happens at exactly that point, such as a crash, popping the
floppy out, or a read/write error on the disk, AFS will fail and leave you
with a corrupted disk that you cannot access at all.

You can see this for yourself; format a fresh AFS disk and copy a few files
to it.  Watch the drive activity light and listen to the head move after
the main write operation is finished.  There should be a pause and then two
distinct drive-head movements before the drive stops for good.   (you might
have to copy 300-500k to the disk before you notice both head movements)
Now copy another small file to the disk, wait for the pause and the second
head movement, then pop the disk out immediately after the second one.  You
should get a requestor on Workbench telling you the disk has a read/write
error.  Cancel it, wait a few seconds and then re-insert the disk, and if
you timed it correctly, the result should be AF0:???  on Workbench.  You
might have to try it a couple times to get the timing down pat, but after a
while, you cand do it every time!

Now, you may be thinking; "If I have to work so hard to make this happen,
then it'll probably never occur on its own." Just think about the number of
read/write errors you've ever encountered, the number of crashes, the
number of times you've forgot and popped a disk out too early etc, and
consider that just one error at the proper time can render the entire disk
unreadable.

AFS comes with no disk salvage or repair utilities and I've been told that
Disksalv 4 will have only limited AFS salvage capabilities.  During my
experimentation, I managed to create a read/write that would not go away,
short of re-formatting the disk, definitely not something you want to
happen on a hard drive.

Please note; I have nothing against the creators of AFS, or their company,
but I think people should know that AFS isn't as safe as it claims to be. 
AFS disks may never get 'invalidated' (a relatively minor problem with FFS
considering the amount of disk utilities available to users) but they can
become unreadable due to a single error.

I know it's unlikely that you could manage to crash the Amiga during the
fraction of a second AFS would take to update the pointers on a good hard
drive, but if you're unlucky enough to get a read/write error in just the
right place, kiss the entire contents of that partition goodbye!