PRODUCT NAME
Professional File System 3, version 5.1.
BRIEF DESCRIPTION
FFS replacement filesystem with enhanced reliability,
speed and feature set.
AUTHOR/COMPANY
Name: Great Effects Development
Address: Hofwijckplein 46a
2515 RL Den Haag
The Netherlands
Web page: http://www.greed.nl
E-mail: info@greed.nl
DISTRIBUTOR
Name: Stefan Ossowskis Schatztruhe
Gesellschaft für Software mbH
Address: Veronikastraße 33
45131 Essen
Germany
Web page: http://www.schatztruhe.de
E-mail: stefano@schatztruhe.de
Phone: ++49 (0) 201 788 778
Fax: ++49 (0) 201 798 447
LIST PRICE
119 DM for a single machine licence,
79 DM for an upgrade from PFS2.
At the time of writing, 1 US$ equals 1.87 DM.
HARDWARE/SOFTWARE REQUIREMENTS
An Amiga with operating system version 2.0 or higher,
equipped with a hard drive. A CD-ROM drive isn't
necessary for actual usage, but only for installation.
At the moment, some of the add-on tools require a
68020 or higher, but this could change soon.
MACHINE USED FOR TESTING
Amiga 500+ with SupraTurbo 28
A590 SCSI controller with Guru-ROM V6
2 MB chip, 8 MB fast
Kickstart 3.1 (40.63), Workbench 3.1 (40.42)
INTRODUCTION
This review can be considered a follow up to Aminet's
docs/rview/pfs2.txt done a few months back.
I don't think it comes to you by surprise, if I say that FFS is
slow and outdated in many ways. You're limited to measly 2 GB per
partition and a total of 4 GB per drive. Even with the finest
hardware, FFS leaves a lot to be desired for, due to it's
not-so-great performance. On the top of that, there's the
validation problem, which gets the worse, the bigger your
drive is.
Here's the problem: should your Amiga crash or something else go
wrong during a write operation (like a power loss or something),
the bitmap of FFS disk will get invalidated. You won't be able to
write anything on the disk, until the bitmap is valid again.
Re-validating the disk is the time-consuming bit here, and it
automatically takes place after a reboot. Basically, it just
scans through _all_ files on the invalid drive(s), so it can
correctly reflect (un)used areas in the bitmap. Doesn't sound
so bad, eh? Well, it's _almost_ bearable on a 100 MB drive, but
try this on 500 MB and above! First the validating takes forever,
then up comes a requester saying something's still wrong (long
experience shows about one time out of four it can't get it
right by itself). Of course, the bitmap is still invalid, so
you're basically screwed. If you don't have a disk repair program,
it's reformat time. If you do have a disk repair program, it's
time for another tedious <insert your disk repair program's name>
session. Not much can be done about all this using conventional
methods, either. Crashes do occur on any given system from time
to time, and as you may or may not have noticed, they usually take
place at the most inconvenient moment.
So, what we need is a filesystem that doesn't suffer from this
kind of problems. Ladies and gentlemen, meet Professional File
System 3, the followup to Professional File System 2. PFS3
supports partitions up to 104 GB and drives up to 2 TB
(2000 GB!) using TD64 or direct SCSI, whilst delivering up
to 500% speed increase over FFS. Most important of all,
your disks are kept valid at all times. No more waiting
for the validation to complete (and praying that it would
get it right this time).
PFS3 comes on CD-ROM, with a manual provided in AmigaGuide
format. Owners of AGA Amigas, who are into gaming, might
be delighted to know there's a bonus game called "Kang Fu"
included.
INSTALLATION
Installation consists of two distinctive phases:
In the first phase, all the required files are copied on
your HDD by the installer script. The actual filesystem
isn't usable directly from CD, as it needs to be serialized
with your name and serial number first. What this means,
is you MUST use the installer script to get started.
The installer lets you choose between different PFS3
flavors; the ones available are Normal, Direct SCSI,
Multiuser, Direct SCSI Multiuser and Floppy versions.
Besides the generic 68000 version, there are optimized
versions of each for 68020, 68040 and 68060.
In the second phase, you need to install PFS3 on the RDB(s)
of your HDD(s) using HDInstTools, HDToolBox or similar
solution. Reading the manual before proceeding with this
is _highly recommended_! The AmigaGuide manual contains
in-depth instructions for installation, with clarifying
screenshot pictures where necessary.
If you're upgrading from PFS2 or AFS, the next step will be
easy; it's just a question of "dropping in" the new filesystem.
PFS3 is fully compatible with PFS2 and Ami-FileSafe and
therefore these two can simply be replaced by PFS3. However,
should you wish to exploit the new PFS3 features to the full,
it would appear that a reformat is obligatory.
Unfortunately, existing FFS volumes need to be
reformatted. PFS3 stores information on the disk in
a different (more reliable and efficient) manner.
Getting your system partition under PFS3 could be
tricky, so here's how I did it (with PFS2 v4.2 to be
exact, but same would apply to PFS3). First, I copied
everything onto another drive and then set up the
RDB with HDToolBox. After this, there was the reboot
bit, in order for the new settings to take place.
I booted up from the Workbench 3.1 floppy and issued
a format command on the system partition, followed by
"copy dh1:dh0backup/#? dh0: all clone quiet".
Now that these two installation phases have been
completed, PFS3 is at your service.
WHAT'S NEW IN PFS3?
PFS3 introduces extra long filenames up to 106 characters.
You can set the maximum filename length from anything between
31 and 106 characters, using the tool "setfnsize". The weird
thing about this tool is that you have to decrease one from
the value it reports, to know what's the actual filename
lenght. In other words, if setfnsize reports the maximum
filename size to be 32, it's in reality 31. The same works
the other way around: if you want to have 106 characters
filename length, you'll have to input 107 to setfnsize!
Confusing, eh? Well, disregarding this illogicality, the
setfnsize idea is good and it works. ELFN's (Extra Long
FileNames) should be good news at least to all MP3 fans.
It often feels like stuffing a size 46 foot to a size 39
shoe, when trying to shorten the longest MP3 filenames
down to 30 characters.
However, one has to be careful with setfnsize, as it is
possible to specify value larger to the current length.
Should you wish to return to lower values, and therefore
shorter filenames, a reformat is required. All the programs
I tried, worked fine with 106 character filenames. I guess
this remarkable milestone means pre-LFN and after-LFN eras
are reality on Amiga, too! :)
It's unfortunately impossible to set the maximum filename
length to FFS standard, 30 characters. The minimum default
is 31 (or 32, like setfnsize likes to think). This is bad
news to all those, who'd wish to retain 100% compatibility
to FFS users. One practical example of the problems that
could arise as a result of this: the PFS2 FAQ included on
PFS3 CD-ROM contains a couple of filenames that are 32
characters in length, but the CD-ROM is obviously mastered
on a system, where the maximum has been 31. As a net result,
a few filename extensions have been cut from .html to .htm,
and you can imagine what effects does this have... Yes, some
documents aren't readable by following the links, or rather
they're highly compliant to the "404 not-found" standard.
I guess I must also mention that the maximum disk label
length is 31 characters, again one character more than FFS
volumes can have. I think these extra long filenames are
a Very Good Thing, but it should be possible to use the
same length limitations as FFS, if one wishes to do so.
There's finally a dedicated disk repair & recovery tool with
graphical user interface, called "PFS Doctor"! Too bad I can't
say much about it, my only experience being a brief test-drive
under WinUAE (the Amiga emulator for PC) and emulated 68020
processor. The program itself is compiled to run on all
processors, but it doesn't work on 68000. So far, it remains
unclear what exactly causes this, but I guess it's either to
GadToolsBox or the required progress.gadget file to blame.
Great Effects Development are probably working on this
problem right now.
The delete directory can now hold up to 992 entries. You can
set the number of deldirblocks from 0 to 32. With each block
holding 31 entries, this translates to various stages between
0 (deldir disabled) and 992 entries. The default is 2 blocks,
equaling 62 entries. Admittably, the deldir is a remarkable
invention, and it's saved me time on several occasions, but
I think things could get very confusing with _that_ many
entries in the deldir! For future versions, I'd like to see
some steps taken to preserve the directory structure somehow,
as this would clear things up considerably. If only the
filenote could indicate the original path/filename, this
would be a good start.
Also, a small tool to erase all deldir entries would be very
good thing to have. Let's imagine you've just deleted 100 files,
sized something like 20 megabytes each. Well, accessing the
deldir naturally causes the filesystem to seek through the
files, obviously to check their integrity (i.e., to see if
they're still in one piece). With that many big files, this
could take a _long_ time. You too see the need for "flush
deldir"? As an added bonus, this would enable one to
instantly get rid of those things that need to vanish
permanently (also called "covering your tracks", but from
who? it depends entirely on person!). At the moment, the
only way to permanently lose something, is to save over a
dummy file as many times, that you have deldir entries.
Multiuser or no multiuser, privacy issues are becoming more
and more important. (Never mind my jabber, there's simply
enough civil libertarian in me to pay attention in these
kind of issues...)
One of the best new things (IMHO) in PFS3 is a proper format
command replacement, called "pfsformat". It also gives you
the possibility to specify the filenamesize and the number
of deldirblocks as well. With verify enabled, pfsformat is
_significantly_ slower than the original C= format command.
Hey, at least it seems to do actual verification work,
unlike C= format! No more problems on large drives either,
so you can forget that quick-format kludge on partitions
residing above 4 GB mark.
Then there's are miscellaneous bits & pieces, making the PFS3
CD-ROM pretty much stand-alone. Such as, Installer 43.3 is now
included, along with HDInstTools and PFS2 FAQ. All this means:
no more installation script problems, you can throw HDToolBox
away for good, and should you develop problems of any kind,
help to most issues is near without the need to connect to
internet.
REVIEW
At the time of writing, I've had PFS3 to play with for a bit
over week. The filesystem itself feels every bit as good as
PFS2 v4.2, even though some of the tools still leave to be
desired for. It's good that PFSLS works on 68000 now, but
PFS Doctor (or Diskvalid) would be very nice too... Oh well,
so far I've managed just fine without any repair-tools, but as
you know -- it never hurts to have some aces up in the sleeve.
It must be noted PFS3 performs slightly better when compared
to PFS2 v4.2, at least on my setup. When backing things
up to DAT tape, the average speed per minute is approx.
1.5 MB higher than with PFS2 ;) Big deal, eh? Well, this
measly increase could very well translate to exponential
performance increase on a real heavy-duty system!
All the same, PFS3 delivers much higher performance than FFS
in all given areas. Simply said, the speed increase is awesome.
Read/write operations, scanning directories and deleting files
was never this fast before! Not to mention, parallel accesses
perform much better. PFS3 makes even directory-cached FFS look
like a snail. On my setup, it takes about four seconds to read
in a directory of 1283 files, using a practical application!
Real-world usage is the best of all tests, don't you think?
The manual states: "volume is always valid, no matter what
happens". It turns out, even switching power off during a write
operation won't damage PFS3 volumes. A technique called "atomic
commit" is used, ensuring correct directory structure at all
times. If a crash or power loss occurs at the time of
overwriting a file, the original file is still in one
piece. No more waiting for the drive(s) to validate.
This is probably the best of all PFS3 features, bound
to save you most time in the long run.
Now to a real-life experience of the reliability factor...
Due to the hot summer, my power supply died, but before
I got a replacement (a PC power supply modified for Amiga
use), the dying power supply caused plenty of momentary
power losses and crashes. Since I was (and still am) unable
to run Diskvalid on my 68000 based A500, I ported an "image"
of my entire system partition over to the PC (using PC2Amiga
and DEV: handler from Aminet). So, I created an appropriate
mountlist for this "hard-disk file" under WinUAE and tested
it with Diskvalid (which would now run, due to the fact it's
possible to emulate 68020 on WinUAE). Out of 10,000+ files,
only three were fragmented! Now, think about your average
FFS volume. Can you claim all your files (except for three
of them) are still in continuous, unscattered chunks after a
few months use? And that defragmenting these few misguided
ones would be as easy as copying them elsewhere and then back?
The only other "problem" (not really a problem, but rather a
sign of inefficiency) with the volume, was that the S: directory
contained an empty directory block (this can sometimes happen
if a directory has been extensively used), and I must say that
directory has been in extensive use! That's all, despite all
the (both deliberate and natural) crashes (and more recently,
power losses) over the months. To be honest, I was kind of
expecting something something more serious. Boo-hoo, now I'm
disappointed! :) Disbelievers, take note: I'm telling the whole
world right here I haven't had any problems, but if you still
feel like emailing me every once in a while, asking if
everything's still all right with my drives, that's
fine with me! ;)
PFS3 is fully AmigaDOS compatible with certain reservations.
Fully compatible, yes, but only at filesystem level.
Applications accessing the disk directly, thus bypassing
the filesystem, won't work if they were specifically
designed with a FFS disk in mind. Disk repair and optimizer
tools are examples of such. Then again, you don't need FFS
disk repair tools for PFS3 volumes, as PFS3 doesn't suffer
from FFS problems. You may also forget disk optimizers when
using PFS3, as the filesystem itself does very good job at
saving data optimally. One of the new listed features of
PFS3 is "improved long term performance". I guess this
translates to a even more intelligent algorithm to
determine data placement. Or whatever. Go figure.
Have you ever undeleted something from an FFS volume?
I'm sure most people have done this, or at least tried
to. Well, with PFS3, you needn't scan the _entire_ volume
for deleted directory entries (and wait for an eternity
for the scan to finish), as there's an invisible
directory called ".deldir" in the root of each PFS3
volume, containing up to 992 latest deleted files.
Restoring files from this directory is as easy as
simply copying them elsewhere. Preferably another
drive, but experience has shown me there's no problem
even if the same drive was used. The only drawback is
the lengthy scanning, if you've recently deleted some
really big files. I mean something like a whole CD-ful
of song-length WAV's or so. You get the idea.
If you've got programs that produce logfiles, you
might appreciate the automatic truncation feature
PFS3 has got on offer. You simply specify the maximum
size for the file and it stops growing indefinitely.
Chances are, if you've got a TCP/IP stack installed
on your Amiga, this feature will come most handy.
As a caveat from an A500 user's point of view (of
course, this isn't applicable to users of Big, Powerful
Amigas), it must be said that PFS is more processor
intensive than FFS. You notice this particularly when
deleting Really Big files from your disk. Still, this
isn't a big deal to worry about, as PFS3 performs
remarkably well even on a 7 MHz 68000. This could
actually be an advantage from a power user's point
of view, knowing that PFS3 takes advantage of faster
CPU's to the full and therefore delivers more
performance.
CONCLUSIONS
PFS3 is well worth a look, particularly if you're fed up with
FFS. After getting my hands on PFS2 v4.2, I decided I won't be
going back to FFS anymore. FFS is completely banned from my
system for several months now. During the whole time I've
used PFS2 v4.2 on my system (ever since the previous review),
I haven't had any disk-related problems, while on FFS they
were a (more or less) daily event.
No, you won't believe it until you see it.
Yes, you will be amazed.
No, you don't want to go back anymore.
Yes, you will wonder how the hell could you put up with FFS.
Here are the pros and cons in a nutshell:
+ No more validate-wait
+ Speed
+ Reliability
+ Big drive support
+ Easy undeletion of files
+ Long enough filenames for all imaginable uses
+ No fragmentation problem over time
- Installation could be hard for novice
or even intermediate users
(- Some of the add-on tools don't work on 68000)
OVERALL: 97%
Even better than trying to cope with FFS and be armed to the
teeth with various disk-repair tools, is to own and use
Professional File System 3. It's an essential purchase to
anyone, who ever experienced inconvenience with FFS.
If you're having any doubts, you should try and get over
them; the only possibility I see for messing things up with
PFS3, would be a result of NOT reading the manual prior to
installation phase two.
HUNGRY FOR MORE?
Besides being on the PFS3 CD-ROM, Mark Harden's
PFS2 FAQ is at the following URL:
http://www.harden.demon.co.uk/pfs/
If you're an A590 or A2091 user, the TD64-compliant
Guru-ROM V6 is the ideal partner for PFS3. See my
A590 FAQ on Aminet: docs/help/a590faq.txt
COPYRIGHT
Copyright © 1999 Timo Rönkkö <deadbeat73@hotmail.com>
This review may be freely distributed and you may do
whatever you like with it. Including, but not limited
to, printing it out and making a silly hat. As usual,
standard disclaimer applies.