PFS3 released on aminet

[Piru]

Excellent news. There most certainly will be a MorphOS port at least, and license permitting it will be included in future MorphOS releases directly.

Current 68k PFS3 already works fine in MorphOS so there shouldn't be any major trouble porting it.

[Piru]

How is PFS in terms of maximum file/partition/drive size?

Filesize limit is 2GiB-1 bytes. Partition size limit (about) 107GiB. HDD size limit is 2TiB as far as I can remember.

Once the current PFS3 is running we'll probably look into cause of those limits and see if it might be possible to adjust them. That'd lead into binary incompatible new version though.

So even if a new incompatible version is created we'll also keep a version compatible with the "original" PFS3 around for sure (so that you can easily mount legacy AmigaOS PFS3 partitions).

[Piru]

i noticed strange attitude to refuse overwriting files, ie looks like certain file (library) v.1 gets overwritten by v.2, but after reboot v.1 is avaliable again instead of v.2. must have something to do with the recovery option, maybe some wrong setting. does anybody else experienced it?

This happens if you don't wait long enough for the writes to get committed to the disk. Wait couple of seconds more before rebooting and the problem goes away.

[Piru]

I wonder if that is a "commitment" problem or a "write-cache" problem.

It's a commit problem and not a write cache problem. Write cache is disabled by default, and needs to be specifically enabled.

PFS3 relies on the atomic commit of the HDD. Use of any sort of write cache that changes the order of which the writes are written to the HDD (be it in HW or SW) will endanger the filesystem integrity. If it would be a write cache problem you'd end up with a totally corrupt FS rather than a missing file.

To reiterate: You get the old file because the filesystem automatically reverts to the state before the final commit. When this happens the filesystem integrity stays intact, but you lose the latest changes to the filesystem. It's far better than losing the filesystem integrity for sure. Also, I have plans to add resethandler support to the FS, making it write out the remaining data to the HDD before letting the system to continue with the reset.

[Piru]

A few problems with large disks have already been reported and I intend to have a look at it.

Have you given any thought to how any future updates to the source code would be distributed? New uploads to aminet would be okay I guess, but something like a SVN repository would be even better. How about creating a project in sourceforge or so?

EDIT: heh, you got there first... :-)

[Piru]

It is good to see there are some people interested in extending PFS and bugfixing. The potential problem of separate incompatible PFS versions has been raised. How about collaborating - enhance PFS together instead of spreading our efforts into subprojects. I could set up a public domain source repository. Github perhaps, or something similar.

Please note that this only makes sense to me if there are at least some people intending to participate. Please let met know.

Michiel

I would be very interested to participate. Years ago I already did some (private) binary patch to PFS3 to avoid certain "beta warning requester" that would pop up if large amounts of changes were committed to the FS (for instance if you deleted more than 1GB of data in a one go you'd easily get this requester). I did this by raising some buffer size. It raised the memory usage but made it possible to delete large amounts (tens of GBs) without any issues. (quick search: It appears to be that ResToBeFreed /* this should never happen */ does happen in some cases Anyhoo now I can see that my patch modified RTBF_CACHE_SIZE for the allocation and the comparison.)

Also I've already mentioned the resethandler improvement I'd like to add. Additionally I'd like to include support for the MorphOS 64bit dospacket interface (even though the FS itself only supports 32bit file sizes so far).

Also improvements to softlink support would be nice thing to have. At least making it work closer to how FFS works.

However, I'll be able to work on this may the earliest.

[Piru]

@Piru
If you doesn't mind, plz, ifdefs all morphos-only specific changes (such as you mention "Additionally I'd like to include support for the MorphOS 64bit dospacket interface (even though the FS itself only supports 32bit file sizes so far"). All the other changes i think should be usable on both oses with no problems.

Not both, but all. I am fairly sure AROS guys are interested as well.

And of course all OS specific changes must not break other builds. As I said elsewhere: "I propose that anyone committing changes must always make sure that the 68k version still builds with the changes."