Amiga OS 3.14 FFS VS PFS All In One

[ExiE]

Originally Posted by AMIGASYSTEM

Yes, PFS and SFS especially offer more guarantees, rare invalidated HardDisk, deleted file recovery and much more.

This is ***** I mean not true.

FFS is still the best regarding data safety and recoverability.
PFS is the best regarding speed but still has issues as Thomas said.

SFS is worst option of all three. Recovery software is not working, last version is from 2007 or so, not recommended at all....

[daxb]

There isn't the truth. I had problems with all three filesystems. It depends. Use what works best for you.

[AMIGASYSTEM]

Originally Posted by ExiE

This is ***** I mean not true.

FFS is still the best regarding data safety and recoverability.
PFS is the best regarding speed but still has issues as Thomas said.

SFS is worst option of all three. Recovery software is not working, last version is from 2007 or so, not recommended at all....

As daxb says nobody is perfect, I used FFS and PFS2/PFS3 on my A4000/060 and A1200/030, FFS was invalidated when the system crashed or when it restarted while I was copying or deleting something.
With PFS2/3 it happened more rarely but it still had the same problem even if I had a small profit on top of the Startup-Sequence that cured the invalidation.
Now for more than ten years on WinUAE I use dozens of HardFiles with SFS and I've never had an invalidation even though I do a lot of tests.

Regarding data recovery, I was referring to the recovery of individual files deleted with the command ".deldir with PFS" and ".recycled with SFS".

This is one of my many systems in SFS that for more than 10 years has never had an invalidation or other problem.
[ Show youtube player ]

[ShK]

Originally Posted by apex

PFS3 is nice and fast, but till it not support 4k blocksize, it will kill your CF/SD soon.

I changed my CF cards to new FFS with 4k blocksize.

Isn't writing anyway split to 130560 bytes ("0x1FE00" = 255 * 512) because of MaxTransfer?

So more important is just align "Blocks per Cylinder" size on partition geometry to math used CompactFlash Card's "Erase Block Size", that two "CF card blocks" are not updated in vain on one write?

CompactFlash "erase block size" varies depending on the manufacturer and brand.

[paul1981]

Originally Posted by Thomas Richter

Unfortunately, PFS still has issues. For example, we had seen here cases where recursively deleting a directory from PFS caused a "object is in use" error, even though no lock was held on any object in the directory. The problem here seems to be that PFS does not delete objects immediately, but rather moves them around, but then as soon as "delete" attempts to delete the parent directory of such an object, barks, at least until the move is complete.

That's nasty...



It seems that choosing SFS for my numero uno Amiga was the correct decision for me. It's been rock solid for me for over ten years now. As for lack of recovery tools as someone else mentioned, I can't say I've ever needed to use any with SFS (touches wood).

[Thomas Richter]

Originally Posted by paul1981

It seems that choosing SFS for my numero uno Amiga was the correct decision for me. It's been rock solid for me for over ten years now. As for lack of recovery tools as someone else mentioned, I can't say I've ever needed to use any with SFS (touches wood).

I'm sorry to disappoint you, but SFS has also problems of its own. We just run into one... The major problem is that SFS uses a clumsy two-level design with two processes involved, so any file system activity goes ping-pong over at least three processes (or four, if you count the device driver in). This is because SFS does not implement multithreading, which means that any I/O activity blocks down all other activities on the same file system. Apparently, Jörg tried to work around this problem by the same means the pre-3.1.4 CrossDos tried to work around, namely by handling some dos packets in the first level, and some other dos packets in the lower second level.

The consequences of this design are that first, the round-trip complexity goes up (see above), some file system activities can lock down the system as they are unnecessily serialized even though a smarter design would have allowed to run them in parallel, and even worse, some activities with SnoopDos may lock down the system completely as snoopDos cannot identify the lower level of SFS as a DOS handler, and hence unfortunately attempts - depending on its configuration - a path expansion. This, again causes a circular dependency of three processes (SnoopDos, SFS lower level, SFS higher level) that may block down the system completely.

I'm sorry to say that some parts of SFS are not at all "smart" in any particular way, in particular its lack of multithreading can be quite harmful (see above: deadlocks, and unnecessary serialization and hence lower performance for parallel operations on it). As it is no longer actively developed, there is little hope that these problems will be cured any time soon.

[PaulG]

I created a new Workbench 3.1.4.1 partition using the newer FFS (4096 block size) which works but my other CF card uses PFS3AIO (PDS?) (1024 block size) which seems noticeably faster.