Path: rcfnews.cs.umass.edu!barrett From: mat@darkside.demon.co.uk (Mat Bettinson) Newsgroups: comp.sys.amiga.reviews Subject: REVIEW: Ami-File-Safe (AFS) filesystem Followup-To: comp.sys.amiga.applications Date: 28 Jun 1995 18:53:03 GMT Organization: The Amiga Online Review Column - ed. Daniel Barrett Lines: 381 Sender: amiga-reviews@math.uh.edu (comp.sys.amiga.reviews moderator) Distribution: world Message-ID: <3ss8ef$uvv@kernighan.cs.umass.edu> Reply-To: mat@darkside.demon.co.uk (Mat Bettinson) NNTP-Posting-Host: astro.cs.umass.edu Keywords: filesystem, disk, commercial Originator: barrett@astro.cs.umass.edu 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: afssales@flevel.demon.co.uk 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 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: mat@darkside.demon.co.uk 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: amiga-reviews-submissions@math.uh.edu Request information: amiga-reviews-requests@math.uh.edu Moderator mail: amiga-reviews@math.uh.edu Anonymous ftp site: math.uh.edu, in /pub/Amiga/comp.sys.amiga.reviews