PFS3AIO v3.1 Final

[Toni Wilen]

Does it happen when using direct scsi mode? (PDS\3 dostype)
DS can be logged more easily (using -scsiemulog command line parameter)

It may be also size related: 600G is in "x4" size range. Does it happen if partition size is "standard" (max 104G)? If not, does it happen if size is about 400G (less than 411G).

When it hangs, does all other operations to same partition also hang?

[ShK]

Originally Posted by Toni Wilen

Even more pointing to some bug or stupid assumption in some patch. I am going to ignore this unless it also happens with OS39BB2 + UAE controller. I don't trust most 3rd party patches, never have, never will.

To reproduce this % issue with PFS3AIO:

1) Make 32GB hardfile (uaehf.device)
2) Create one bootable partition with PFS3AIO
3) Install Amiga OS 3.9 + BB2
4) Create textfile, size 2GB-1 (WIN10: fsutil file createnew 2GB.txt 2147483647)
5) Copy that file 11 times to PFS3AIO partition and % counter will rollover



6) Redo with FFS ---> % counter does not rollover

[mpattonm]

Originally Posted by malko

Download the pfs3 package from aminet. It contains the documentation/faq/etc. But install the new pfs3aio from Toni of course

Thank you!

[Toni Wilen]

Originally Posted by ShK

To reproduce this % issue with PFS3AIO:

1) Make 32GB hardfile (uaehf.device)
2) Create one bootable partition with PFS3AIO
3) Install Amiga OS 3.9 + BB2
4) Create textfile, size 2GB-1 (WIN10: fsutil file createnew 2GB.txt 2147483647)
5) Copy that file 11 times to PFS3AIO partition and % counter will rollover



6) Redo with FFS ---> % counter does not rollover

Thanks, much better

I'll check but I still think it is WB bug/some stupid assumption. Does it happen with 18.5 pfs3? (It probably does)

[malko]

@TuKo & @ShK : Out of curiosity, did you try to run pfsdoctor (see post #1 - at the bottom) ?

Does running it change the display of the "full %" ?

[TuKo]

No change with either old pfsdoctor or experimental one

[malko]

OK. Thanks for giving a try

[Toni Wilen]

It is WB calculation overflow. ACTION_INFO id_NumBlocks and id_NumBlocksUsed are correct.

I remembered PFS3 internals wrong, returned block size is always 512 (not 1024 that is PFS3 metadata block size or larger if large partition). Same overflow should happen if FFS formatted with block size 512.

Returned block size can be faked as a workaround, the larger the block size, the smaller total block count becomes, allowing larger drive without 32-bit overflow in free size calculations. (Recent WinUAE versions directory filesystem does this, fakes block size up to 32k)

WB most likely uses "in use blocks" * 100 / "total blocks" formula to calculate in use percentage where "in use blocks * 100" 32-bit overflows. Overflow happens when about 20G (if 512 block size) of disk is in use. If 1024 block size, overflow happens when about 40G of disk is in use and so on..

btw, there was another WB overflow hint: change height of WB window and when height is small enough, disk usage bar suddenly becomes correct.

[ShK]

Originally Posted by Toni Wilen

Does it happen with 18.5 pfs3? (It probably does)

Yes.

PFS3-020ds 18.5: Fails
PFS3AIO 18.5: Fails
FFS 45.1: OK
SFS 1.1280: OK

[antiriad76]

Originally Posted by Toni Wilen

Does it happen when using direct scsi mode? (PDS\3 dostype)
DS can be logged more easily (using -scsiemulog command line parameter)

It may be also size related: 600G is in "x4" size range. Does it happen if partition size is "standard" (max 104G)? If not, does it happen if size is about 400G (less than 411G).

When it hangs, does all other operations to same partition also hang?

I tried DS mode (PDS\03) and I am able to copy files over without any hangs however when I reboot the 100GB and 460GB+ Partitions go back to UnInitialized and I have to reformat them.

I have tried formatting via PFS3Format and from within WB with the same results.

Could it be because I have entered the HDD Data manually?

Cylinders: 77764 (595.6GB)
Heads: 255
BpT: 63
BpC: 16065

Also which the Defacto Tool of choice when partitioning a Drive? There are so many programs I have tried and they all give me different data (HDInstTools, HDToolBox etc)

[Toni Wilen]

Are you trying to debug possible pfs3 issue or something else? Your test case has far too many unknowns that has nothing to do with pfs3, making it offtopic here..

[kolla]

I would avoid HDInstTools, and stick with HDToolBox from OS3.9 (and in the future, I guess, from 3.1.4).

(and yes, suppose this is off-topic - but PFS3 comes with HDInstTools, so there is a link...)

[antiriad76]

Originally Posted by kolla

I would avoid HDInstTools, and stick with HDToolBox from OS3.9 (and in the future, I guess, from 3.1.4).

(and yes, suppose this is off-topic - but PFS3 comes with HDInstTools, so there is a link...)

I have tried HDToolBox but the problem I have it that it creates a gazillion partitions automatically which causes the OS to crash when I try to modify the partition table.

Any way to prevent HDToolBox from creating partition automatically?

[kolla]

Ah yes, the default setup is funny on large drives Though I never had any problem with it causing crashes, I just hit the drop down menu to the right that says "Default Setup" and pick the number of partitions I want - this causes crash for you? What kind of crash?

OK, this is off topic, please message me

[Toni Wilen]

http://www.winuae.net/files/b/pfs3aio_v3.1_test1.zip

- Fixed softlink support, they have always been broken (Piru). I have never used softlinks so I have no idea what happened previously.
- TD64/NSD check also validates returned io_Actual value.
- ACTION_INFO InfoData returns fake block size to work around overflow in programs (including WB) that use 32-bit "in use * 100 / total blocks" formula to calculate size. Returned block size depends on partition size. (This is only visual change, "real" block size in DosEnvec is unchanged). UAE already did this with very large drives without side-effects.

TODO: If I manage to hook up filesystem loading to new UAE debugger, I'll try to find out if there is any obvious ways to reduce memory usage when running on low memory systems.

[TuKo]

Confirmed working.

[kolla]

Originally Posted by Toni Wilen

http://www.winuae.net/files/b/pfs3aio_v3.1_test1.zip

- Fixed softlink support, they have always been broken (Piru).

Aaaah, that might explain something. I use to softlink WBStartup to different directories, depending on whether running Workbench or DOpus (well, SYS:WBStartup -> T:WBStartup.dir -> SYS:WBStartup.WB, for example, so only writing to ramdisk on boot) and somewhere along the timeline this stopped working as it did, I never linked (huhuh) to pfs3aio, I will check it up again

Oh, and Piru is still around? That's great! His probably most used piece of software, WhichAmiga, could perhaps need an update too, hehe

TODO: If I manage to hook up filesystem loading to new UAE debugger, I'll try to find out if there is any obvious ways to reduce memory usage when running on low memory systems.

Cool I have plenty of low-end systems to test with.

[Toni Wilen]

Managed to get filesystem debugger working.

I can reduce memory usage about 30k if I decrease size of internal buffers/caches (not same as addbuffers/hdtoolbox buffers). Not yet sure if it causes any side-effects and how to enable it, perhaps if buffers are small enough or with some new dostype. But on the other hand 30k probably is not worth the trouble.

[E-Penguin]

Is that 30k per partition? That might start to add up for some people

[idrougge]

Originally Posted by Toni Wilen

TODO: If I manage to hook up filesystem loading to new UAE debugger, I'll try to find out if there is any obvious ways to reduce memory usage when running on low memory systems.

That's welcome. I don't use such systems myself, but if I disable my accelerator, I appreciate if I'm able to even have my HD active.