PFS3 released on aminet

[ChaosLord]

And unlike with SFS, it would be nice if there was a SINGLE "ng" codebase available for all platforms (68k, MorphOS, AmigaOS4, AROS) so there would be absolutely no compatibility issues...

+1

[x56h34]

Awesome news. Thanks so much.

[nicholas]

Yay!

Thank you so very much!

[nicholas]

And unlike with SFS, it would be nice if there was a SINGLE "ng" codebase available for all platforms (68k, MorphOS, AmigaOS4, AROS) so there would be absolutely no compatibility issues...

I certainly hope so, though one can't speak for the guy who forked SFS and made it incompatible with the 68k/AROS/MorphOS versions.

[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.

[ChaosLord]

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

[Cammy]

Thank you, Michiel! Just in time for my two new 8GB CF drives which I plan on preparing and installing this week.

[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.

[ChaosLord]

Thank you for your explanation Piru.

I had been theorizing that PFS3 secretly had a tiny write-cache.  That would explain the super tremendous speed of PFS3 and wawrzon's problem.

In any event I hope that PFS3 gives you many hours of coding pleasure.

[ChaosLord]

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.

That sounds very gr00vy!!

[Gulliver]

Thank you Michiel !!!

[magnetic]

Thank you Mr Pelt. Your FS is legendary in the amiga world... So this is availble on aminet for free now or just sources? I'll have to change over my FFS partitions to PFS now

[NovaCoder]

Thankyou muchy

[runequester]

So for those of us who aren't smart, how do you change the file system of a partition?

[Damion]

Excellent! Many years of happy use here, without a single hiccup. Thank you!

So for those of us who aren't smart, how do you change the file system of a partition?

The PFS3 docs are very good, that's where I would start. It's not terribly difficult, but you'll need to reformat. It's worth it, the difference in performance (especially from FFS) is instantly obvious.

[XDelusion]

Double Plus Good!!!

I've heard great things about this software, at last I can finally check it out for my self (because I was too cheap to register). Thank you very much!