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 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ö 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.