Episode 1: FFS vs PFS3 on YT

[Thomas Richter]

Originally Posted by CmdrAmiga

@Tomas, no offence but exactly for that reason this video has been made. I am enough of technical data about how wonderfully some piece of software has been made. I'm an end user and I don't really care if the dev used the latest compiler or wrote it in assembly, or the structure of his program beats other products on paper. What I care is practical efficiency and that can bee seen on the video very clearly with overwhelming results (I didn't expect such a difference to be honest so I'm double happy that I made it). It wasn't meant against FFS. I was (and still am with some exceptions) a long time user of this file system. But I wanted to see how much the difference can be. I shared my work with the community but I leave the conclusions to draw for others - I have my answer.

First, you miss an "h" there.

However, this is not about "technical features" of a filing system, but rather its real-time performance. However, what "performance" means depends on the circumstances, you cannot just neglegt that. Do I list many directories? Do I access many files? How large are the files? What is the CPU performance? How much of the performance of the system is taken by the file system?

All these are "down to earth" numbers that play a relevant role in partical applications. It is not about the "niceness of the code". Which is, for the FFS, not so nice at all, but at least, it shows that the thing was designed for parallel multithreading operation, which does not hold for all file systems.

Try to copy a file with FAT95 and open a window on the workbench, and you'll see what I mean. If this isn't practical, I do not know.

Second, let me stress that I am not a particular fan of FFS. FFS is, with mild variations, the file system of Tripos, and it shows its age and its design problems. However, it is neither as bad as some people want to make me believe it is. Nobody would write a file system as primitive as FFS today, but even though the structure is rather simple, its implementation is quite elaborate, with many many operations able to run in parallel. I have never seen this amount of co-routines interleaved to each other anywhere else, and I should know as I made both CrossDos and CDFileSystem parallel file systems that do not block you. Unlike most other file systems on the Amiga (both SFS and FAT95 are single-threaded and "block you out" if they are busy).

[CmdrAmiga]

@Thomas, my video doesn't say FFS is bad. It simply shows that PFS3 is faster, a lot faster in those two operations I chose. It wasn't meant to discredit it, it was to see the difference. Granted, it doesn't show a lot of other aspects of those file systems but it's just the first episode. I do it out of curiosity so you all may expect more tests to come. And I'm not going to favour any of them, the results will be posted no matter what they say about PFS3...

Next episode is available on YT. Enjoy :-)

PS Sorry for the "h".

[Mad-Matt]

What was the block size for the FFS partition as that will have a notable effect on speed.

I use both filesystems for different reason including speed and data integrity. I'm only on a lowly 040/25 so speed isn't great to begin with (slower disk access than an 030). Anything important or in need of backup I put on ffs as the recovery tools are better should issues occur (Which I've never had since the os35 ffs update).

[thomas]

Originally Posted by CmdrAmiga

I'm an end user and I don't really care if the dev used the latest compiler or wrote it in assembly, or the structure of his program beats other products on paper. What I care is practical efficiency and that can bee seen on the video very clearly with overwhelming results (I didn't expect such a difference to be honest so I'm double happy that I made it).

I could have told you I bought PFS2 when it was first published in Germany and I was (and still am) quite impressed of its speed.

But don't you think it is a bit short-sighted if you look solely at speed? There are other aspects of a file system, even from a user's perspective.

The first thing you recognise after converting from FFS is that you have something like 20% less space. This is because PFS reserves the beginning of the partition for directory data and reports only the file part of the partition as free space.

You could live with that, knowing that the free space shrinks more slowly as with other file systems because new directories and directory entries take up no space.

But there are two extreme scenarios when this comes into account:

Imagine you have a huge collection of icons organized in a highly hirarchical directory structure so that you have many many many directories with many many many small files. In this situation you could run out of directory space before the file space is filled up. The partition might report several megabytes of free space but every attempt to save a new file will lead to a disk-full condition.

The opposite might happen, too. Imagine you want to save a single 2GB file on a 2GB partition. After formatting you might end up with only 1.8GB or so free space. And you cannot get these 200 MB back, even though they are completely unused.

By concentrating directory data in one place you also have a single point of failure. Did you ever do something stupid with a low-level program like DiskSalv, Defrag, ShapeShifter, PC-Task or the like or even with Sys:System/Format? Started to format a partition and then recognised that you chose the wrong one? With FFS the damage might not be too serious. FFS starts its directory in the middle of the partition and stores directory data with the files. Overwriting the beginning of the partition might still allow to recover most if not all of the files and directories, depending on the fill level of the partition and how quick you cancelled the format operation.

With PFS the first part you overwrite is the complete directory. Without any meta data it is next to impossible to recover any files, even if the data might be completely intact. You just don't know and cannot work out where it is.

Next thing you might recognise as a user is the deferred write function: Open S:Startup-Sequence in an editor, add Set Echo On to the beginning, save the changes, exit the editor and reboot. Oops. Nothing changed. The line you added was not saved. PFS keeps changes in memory until traffic goes down and only then writes out its buffers. This means after you saved something you have to wait something like five seconds before you reboot. Otherwise your changes are lost.

Imagine you record some streaming or write some continuous logging and it is important to commit all received data to disk. With FFS after a crash/reboot all data is there. It might require to revalidate its bitmap, but the data you wrote to the file is still present.

With PFS it might happen that the whole file is not there or is completely empty, although you were recording several minutes of data before.

The next feature is not so obvious to users, it just assures that the file system structure is always consistent and has never to be validated. They call it atomic commit.

What they do is to allocate new directory blocks for each change and only when all changes are saved to new blocks the whole chain is linked to its parent. In practice this means that a single directory block (the parent) will be rewritten for each and every change. So especially for flash storage this might wear out single cells quickly.

Don't get me wrong: PFS is still my beloved baby and I recommend it to everyone for its easiness, robustness and of course its speed.

But saying it is the best in all aspects, only because it is ten times faster than other file systems in one discipline is just wrong and depending on the purpose you want to use your Amiga for it might even be dangerous.

[CmdrAmiga]

@Thomas, you write really interesting stuff about the file systems, I mean it. But you're missing one important thing: The video I posted is titled Copying and packing - nothing more, nothing less. That being said, it doesn't claim to be a compendium of the knowledge about every aspect of the FS. Its goal was to compare those two simple and most used actions on Amiga (at least in my case). There is time and place to do more tests and when they are completed, at least up to some degree, then we'll have a better picture. Until then that sheds some light on the matter and I bet many will appreciate such an initiative.

@Mad-Matt

What was the block size for the FFS partition as that will have a notable effect on speed.

1024 for both FS. And since you wrote 'it will have a notable effect on speed' I will carry a test to see whether you are right or... it's just another myth ;-)

[Amiga1992]

Originally Posted by CmdrAmiga

The video I posted is titled Copying and packing - nothing more, nothing less.

I think you are now just getting weird about not accepting any kind of criticism to your video which is odd.
You have been told by two people, one who made the current FFS(!), and the second one very knowledgeable in Amiga file systems, why your comparison isn't all there is to it in regards to speed. These people know a lot more than you or anyone else do about the subject, and it doesn't matter if you are an end user, their input is very important: the tests depend very much on your testing environment and other factors.

Like, you have an 060, which most people do not. So if I do the exact same test on my 030@50, it might be completely different.

By the way, the actual video title, not what is in the video, but what is in the metadata and ends in search engines, is just FFS vs PFS3, so that makes it seem more encompassing than it actually is. "FFS vs. PFS3 - Copying and packing speed on a 060" might have been a better title.

[meynaf]

Another source of bias to eliminate is the quantity of file system buffers.
If PFS uses heaps of memory to cache data and FFS only has small buffer size (see addbuffers command), then it's not fair.

[nikosidis]

And some are trying to sell classic OS update and others don't. I bet my ass FFS will never boot the system as fast as PFS3 no matter what you do. I hope Tony will come into this thread.

[gulliver]

No one is selling you anything here.

And for that matter you should see who contacted PFS3 author to make it available before spitting nonsense (use EAB's search function).

This is not about any conspiracy.

We are all interested in seeing valuable tests because we all enjoy the subject and would appreciate some objectivity.

[meynaf]

Originally Posted by nikosidis

I bet my ass FFS will never boot the system as fast as PFS3 no matter what you do.

You can try to beat my 7sec cold boot / 5sec warm boot if you want.

[CmdrAmiga]

@Akira, instead of jumping on me with another pointless critic how about:

Mate, could you repeat the test with a lower hardware specification and with the following method... I'd appreciate it?

I assure you it wouldn't hurt. And IF you think you would chose a better title and would do a better test then please, be my guest.

@Meynaf, if you saw the video you would know that I GENEROUSLY gave the FFS partitions 1000 buffers each, while PFS got only 80. I won't even mention that having 4 MB of Fast RAM you could not afford it so please stop trolling.

It's really sad that in every interesting initiative there has to be always a stupid and poisoning polemic driven by trolls that can't pass by without pointing something out and call it a "constructive critics".

How is it that most people find the tests interesting, have some reasonable suggestions and understand that it was just a simple test, not a "witch hunt"? Why do you see an attack in something that wasn't meant to be and doesn't comment it that way? What hurts you feelings? I don't get it. C'mon on guys, chill out.

[meynaf]

Originally Posted by CmdrAmiga

@Meynaf, if you saw the video you would know that I GENEROUSLY gave the FFS partitions 1000 buffers each, while PFS got only 80. I won't even mention that having 4 MB of Fast RAM you could not afford it so please stop trolling.

I saw the video and guess what ? I had to look at it again and pause the video to actually see that.
But at no moment you could ever just imagine i could simply have missed the info, no, you start by charging me of trolling. Which looks a lot like purely emotional reaction, btw.

Another thing, 1000 buffers for FFS take a little more than 500kb. Doing that for 4 partitions (you needed only 2) takes a big 2MB, so you can afford it with 4MB.

Originally Posted by CmdrAmiga

It's really sad that in every interesting initiative there has to be always a stupid and poisoning polemic driven by trolls that can't pass by without pointing something out and call it a "constructive critics".

I'm real sorry, but there can not be such a big difference by just changing the file system, so there has to be something wrong somewhere in the test.
Perhaps due to delayed writes. We don't see HDD led so how can we know when exactly it stops and it can safely reboot.
We are also not sure how the config is physically. If both source and target are on same drive, not the same as if they are on a different one.
Of course the whole story could just be a fake, and whether it is one or not, it would still look exactly the same. Not that i am saying it actually is one.

Originally Posted by CmdrAmiga

How is it that most people find the tests interesting, have some reasonable suggestions and understand that it was just a simple test, not a "witch hunt"? Why do you see an attack in something that wasn't meant to be and doesn't comment it that way? What hurts you feelings? I don't get it. C'mon on guys, chill out.

If it's not a witch hunt, it dramatically looks like one nevertheless. Or like some disguised ad for PFS, i don't know. Or some hatred for FFS. How can we know ? All we saw is FFS biting the dust by a large, suspicious, questionable margin.
I'm not saying it is intentional. But there is something.
Btw. You did not test FAT95 or SFS. Why only FFS vs PFS ?

[nikosidis]

Meynaf is not a troll. He never was, never will be. It is an interesting thread and everyone should be open for the best solution for our Amigas. I'm no tech. guru and never tried FFS after OS 3.1. I know there been some updates to it from OS 3.5 or 3.1.4. Looking at this video FFS is still slow doing basic operations. Real world use is what most are after. If FFS is better at playing Doom while backup your whole partition it is not of any interest to most. You just don't do that on Amiga no matter what configuration you have.
It is neither safe and will slow down you computer a lot no matter what file system.

[meynaf]

Thinking again about the buffers, it could be interesting to try the following commands : avail, then addbuffers (with some value that is accepted), then avail (a second time). And of course post the results here. This way the amount of used memory becomes obvious to everyone and there is no discussion anymore. Because with 4MB you could afford it, really.

[CmdrAmiga]

@Meynaf, let me tell you this again: I wanted to see by myself which of the file systems is faster. I mean, I knew PFS3 is faster but didn't know how much. I saw the results only during video editing and I was sincerely surprised (which means I did not discriminate FFS). I just simply shared them with the community. I am not related to PFS3 or an adversary of FFS. I bought 3.1.4 and I use it on some of my entire hard drives. I have never said that FFS is a crap or that the PFS3 is the best! I just started to running some tests and that was merely a first episode. I'd like to continue doing different tests and I'm open to constructive and practical suggestions. Really there's no need to see manipulation in my results or any kind of promoting a specific file system. If you look through this forum or another then you'll see this topic is bouncing again and again. So that means there's a lot of people interested in it with lots of questions. Seeing a video, or even better a series, would give them at least some answers in an easy way. Granted, it's not thorough and touches only some aspects of the FF but I do not draw any conclusions at the end of my videos, I do not comment them nor suggest they should choose this over that one. I leave the judgment to the viewer. Here, on the other hand, we may comment and suggest but please let's do it in peace without accusing anybody of any malicious intentions

PS I'm finishing to edit another test that includes SFS ;-)

[meynaf]

That's ok, no harm meant

However there are still results to explain. Really, FFS shouldn't be that slow.
Some years ago i've had some CF (on internal A1200 IDE) being a lot slower than it should have been. Oh, yeah. But I could fix that.

So, could you please show the parameters used to mount the FFS partition ?
From HDToolBox it's on the page used to change to another file system.
If you're using another partitioning software, it's where the (in)famous "maxtransfer" value is shown.
I'd like to see all values there. Just to be sure.

You said yourself you were sincerely surprised by the results and this is a good reason to try to eliminate all possibility of a bias in the tests. You can count on me to help achieving this goal.

[nikosidis]

Meynaf: Here is my A600 with Furia 020/37MHz PFS3, warm boot.

[ Show youtube player ]

[meynaf]

Originally Posted by nikosidis

Meynaf: Here is my A600 with Furia 020/37MHz PFS3, warm boot.

Ctrl-A-A at 0:04 and WB ready at 0:10, that's a nice 6sec warm reboot
Still, not faster than my A1200 (with B1230/50) was with FFS on mechanical HDD.

Another comparison - PC laptop reboot : more than 1 minute. Who said 'modern' ?

[nikosidis]

Meynaf: Haha yes. I also have A1230/50 but it is so much crap there so warm reboot take longer I can try to remove user-startup, and stuff in wb-startup to test. Lets see

[CmdrAmiga]

New video has been uploaded:

[ Show youtube player ]

I used lower configuration this time (due to some unhappy users ). Instead of a 060 the tests ran on a Blizzard 1220 28 MHz + 4 MB Fast RAM.

I'd like to od a similar test but with a mechanical hard drive to see if those values changes much or not so.