Welcome, Guest. Please login or register.

Author Topic: PFS3 questions and observations  (Read 2572 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline LoadWBTopic starter

  • Hero Member
  • *****
  • Join Date: Jul 2006
  • Posts: 2901
  • Country: 00
    • Show all replies
PFS3 questions and observations
« on: September 09, 2012, 10:35:08 PM »
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.
 

Offline LoadWBTopic starter

  • Hero Member
  • *****
  • Join Date: Jul 2006
  • Posts: 2901
  • Country: 00
    • Show all replies
Re: PFS3 questions and observations
« Reply #1 on: September 10, 2012, 03:50:17 AM »
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.