PFS3 questions and observations

[LoadWB]

This weekend I've decided to re-do a 10GB partition on my 18GB hard drive to use PFS3 instead of SFS 1.279.  I have been easily able to do so using a USB2 flash drive and lha.  I am using PFS3 from Aminet, which reports itself as "Professional-File-System-II 18.5".

My first observation is that PFS3 handles directories with a shyt-tonne of files much faster than SFS (in particular YAM email folders and drawers full of icons,) and also seems to handle mass deletions much more quickly.  My second observation is one which has had me stymied most of the weekend: do not forget to setfnsize on the newly created volume or you'll be stuck with 31 character file names.

My last observation is also a question: it is apparently a long-standing "missing feature" of PFS3 to not report its version when queried by icon Information or "version :" and I am wondering if this will be added any time in the future.

I noticed the Mask for the partition was set to 0x7FFFFFFE rather than the recommended 0x7FFFFFFC and wondered if PFS3 really cares about that?

The default setup for this drive is 1k block sizes.  PFS3 FAQ says only 512 byte block sizes are supported.  What is the current status of this support and for what kinds of users does it matter?

I think that's it for now.  Since I've set my file name size limit much higher than the default lha has stayed busy happily restoring my files.

[LoadWB]

I've learned a couple of other things during this process.

After the first extraction "succeeded," I found that there was a major discrepancy in the number of files on the volume as reported by icon Information versus the number of files in the archive as reported by lha.  I ran lha with "-t" option, to only extract new files, and found the Workbench as a whole came to a stop at some point in the process, usually around the same file.

I tested the archive with lha and 7-zip and found no errors.  Then I ran PFSDoctor to find that it had to repair two directories.  Afterward an entire drawer was missing from the drive.  I ran lha with "-t" again and everything finished successfully.

But I found that I still had a number of files missing (about 126 files,) and the byte count was off.  I opened the archive with 7-Zip on a non-OS-specific Intel-based machine and fired up DOpus on the Amiga and ran "Get Sizes" on all of the contents.  I compared byte and file counts on both to find that all but a single file had extracted.  Effing weird, but I now none-the-less have a working PFS3 volume.

Now, something else I determined which I think will be of interest to anyone else doing this process with a USB flash drive.  During this process I was running MiamiDX and a USB Ethernet device.  I have seen on Windows machines where the driver crashes and the USB Ethernet device locks up the entire network, and that's exactly what happened in my case -- the entire network became non-responsive.  (I didn't bother to run any packet capturing on the network since the switches indicated no traffic what-so-ever.)

The USB flash drive was still running full-tilt.  I brought up MiamiDX and put it offline then brought up Trident and disabled the Ethernet device, which put everything back to rights.  (This actually happened during a previous extraction, as well, and I was able to just power-cycle the device as well.)  Returning the Ethernet device back to service is easy: power-cycle its parent hub or reboot the machine.

Hope this information is interesting or useful to someone.

[Bamiga2002]

My second observation is one which has had me stymied most of the weekend: do not forget to setfnsize on the newly created volume or you'll be stuck with 31 character file names.

AFAIK you can set FNSIZE afterwards with PFSUndelete program.

[jedcooper]

i also had issues with SFS, FFS, PFS regarding long filenames.
now i finally put the latest and freeware (?) version of PFS on my A1200 with a <4GB HDD.

i partitioned, updated etc. and formatted the disk as described in the guide.

AND !IMPORTANT! set the filelength to 107 for every partition.
no problems since then again with long filenames!

everything's fine now, DOpus 4.12 can't handle the long filenames, as it could in FFS/SFS (but SFS sometimes failed) so i have to use DiskMaster2 now for fiddling around with files. :-/

[kickstart]

Im still using FFS on a CF and want to use these speed up of PFS, but im afraid to loss my mods and scene collection from my first a1200.

[jedcooper]

Im still using FFS on a CF and want to use these speed up of PFS, but im afraid to loss my mods and scene collection from my first a1200.

what about a backup? PCMCIA -> CF and you're done. BUT! i recommend to LHA ALL the files first and only put the .lha file on the CF because i seldom but had issues of not correct information of files saved in fat95 on CF. with .lha you preserve amiga filestructures. and can extract on windows machine with f.e. 7z.

btw. you DO HAVE TO format and copy all files back if you setup new file system for a partition. but you can do step by step if you got big/more partitions, copy one to another, install filesystem on one, format, copy another back to one... etc.

[jedcooper]

about performance:
did some tests with SysSpeed V2.6 and PFS > SFS > FFS.
only some deletion of files is faster in FFS.
don't know how representative the results are, but i did more than one test with every filesystem believe me
PFS so far was a good choice. no issues anymore here.
 
btw: i was asked for the link of PFS "freeware" it's on aminet. even KS1.3 version. n1!!!

[kickstart]

@jedcooper

Yes, a lha of entire partition is the best solution, some time ago had some problem with some files copying one for one to a SD fat formated.

ps: this link is the latest version of PFS?

[jedcooper]

ps: this link is the latest version of PFS?

the kick 2.0+ version (i use it with 3.1 kick and 3.1 OS) as far as i know and can see on aminet. v5.3.
the filesystem itself "says" another version installing to RDB f.e. but that's normal or nothing to worry about.
the package is v5.3.
i must admit i did not test or further investigate the kick 1.3 version