Michiel Pelt has released the PFS3 filesystem source code on aminet. This means there will be a MorphOS native version at some stage (I'll likely be working on this myself at least).

The current 68k PFS3 works already in MorphOS (but it's a bit awkward to use with Apple HW for instance where there is no RDB). License permitting the native MorphOS port will be incorporated in the future MorphOS boot images allowing easier usage with Apple gear as well.

News post by mr Pelt: http://www.amiga.org/forums/showthread.php?t=57328

[ Edited by Piru 10.04.2011 - 21:13 ]

What are adventages over SFS or even IceFS?

PFS3 is faster than SFS. I haven't been able to check IceFS but my understanding is that IceFS performance is close to SFS.

SFS slows down considerably over time, while PFS3 doesn't. I have no experience with IceFS here, but I'd think it doesn't slow down over time like SFS.

PFS3 doesn't do large files and has a partition size limit of 107GiB. IceFS has clear edge there.

[ Edited by Piru 10.04.2011 - 21:10 ]

So PFS3 has a partition limit that is smaller than SFS.
What's the limit on file size?. I haven't run into the limit under SFS even with DVD rips.

Quote:

Yep, pretty much.

Quote:

Yep, IceFS has 128K metapools, filedata preallocation and TLSF allocator
which all helps. No experience with PFS3, I've just heard its a very fast FS.

So what about trying to get this two filesystems to work together? I mean take all the best from two of them and make one good filesystem? I know that IceFS is a commercial product but meaby Team and author will find some kind of agreement?

Quote:

Hey, why not throw in also some bits from Ext4 and NTFS and atleast
5 more filesystems and we could end up with a real super FS !? :)

Although I have already purchased the IceFS, this is good news that a native MorphOS PFS3 will be available as part of the the MorphOS2.x boot.img in the future. Thanks for that info Piru.

/docs/pfs2.h missing for pfsDoctor! :)
It will not be an easy job to port all this...

SixK

I just think it would be easier to port ZFS as it is a stable system which, AFAIK is open source and would relieve many issues we have with current systems

Quote:
That is one of the stupidest comments I've heard. Ever.

Porting ZFS would be pain in the behind. ZFS requires ton of various infrastructure around it.

I'm not saying that ZFS would be a bad idea, but it certainly would not be easier to port.

[ Edited by Piru 12.04.2011 - 10:28 ]

Quick update:

Due to renovation in my flat I don't have access to any MorphOS box. This didn't stop me from working on PFS3 though. It took a while to get the cross compiler setup working on AMD64 but we were finally successful.

I've replaced all the assembler code with C and fixed the code enough to make it build with GCC. The code builds and links ok, but is largely untested. There are still some issues that need to be fixed though: For instance there actually is some static data that needs to be removed in order to be able to place the filesystem inside the boot.img. The porting process has gone rather smoothly so far.

Obviously there's still PFSDoctor and other tools that need to be ported as well.

[ Edited by Piru 15.04.2011 - 18:18 ]

If you need beta tester,
I may have space remaining on my Mac Mini to create a PFS3 partition...

SixK

Nice status update Piru.

This is a great effort... thanks !

@Piru
Quote:

Hmm, inside the boot.img; Is this something you guys are targeting to a MorphOS 2.8 release already, or will it come in 2.9?

Piru,
Quote:
Although I guess meanwhile, a damaged PFS3 partition with MorphOS native PFS3 could still be fixed with the 68k version tools?

Thank you for the beta test offer, but I should be back with my peg2/mac mini/PowerBook in a week or so.

Meanwhile the new code will remain mostly untested, and while it will likely end up in the SVN soon I would seriously caution anyone from trying it yet. NOTE: The changes do nothing to the SAS/C 68k build of course.

As a precaution I'm leaving the MorphOS Makefile uncommitted for now. That should stop all but the most dedicated testers I think

Quote:
Honestly I'm not sure yet. I'd guess it depends on if the source can be brought to PFS 5.3 level (I think it's very close already, except for PFSdoctor) and the remaining bugs fixed (I get the "Beta warning requester #1" with the 68k PFS3 5.3 while the bug is supposedly fixed!). Also, I'd very much like to see the PFS3 softlink support improved (it doesn't work very well with ixemul and relative softlinks, making GG environment on PFS3 partition slightly painful to use).

Of course there also is the current 100GiB partition limit which kind of sucks as well. There are some ideas on how to raise this limit, but I think all those result in incompatible filesystem... As you can see there are a lot of things to consider.

Quote:
Yes, as long as the FS remains binary compatible. For instance raising the partition size limit would require new repair tool (I think).

However, the 68k PFSDoctor is somewhat buggy & picky about the environment it is run on: Basically I run it by booting without the startup-sequence (and without invzeropage!) and then launching the app. The GUI is quite horrible GadToolsBox mess and works only so-so. Perhaps a MUI GUI could be created for it.

[ Edited by Piru 15.04.2011 - 22:32 ]

PFS3 is my fav Amiga FS on Amiga and on MorphOS.

It's great to hear that one day PFS3 will be on MorphOS. I used this FS on all my old Amiga classic computers and I remember it was was fantastic!
Thanks for your effort Piru.

@Piru

Forgive my ignorance of earlier comment, I know every little about porting or writing code but I just was thinking, to bring PFS3 up to speed will take some effort.

Update:

I just finished porting the tools, including PFSDoctor (but it should be added that a lot of work remains to be done: testing, bug fixing, perhaps adding a MUI GUI to PFSDoctor etc). This leaves FloppyPFS basically. I'm not sure there's much use for it.

[ Edited by Piru 17.04.2011 - 02:28 ]

Piru

Wow that was fast! :)

does that mean someone can add an infinite drive space mode? where i can keep putting files there and as the drive get's full when it runs out of space, the oldest files (based on last access date/time) automatically get deleted? this will help a lot for temporary stores such as holding bays, download folders (where you may not care about the oldest stuff)... means no more storage headaches for this type of environment...