Max. partition size in AmigaOS4.1 (SFS2 handler)

@geennaam
Quote:I don't understand why you even tried that, I wrote several times already, and of course it's mentioned in the SFS readmes as well, that SFS uses 32 bit block numbers resulting in a max. theoretical partition size of 2 TB with 512 bytes/block

Quote:TD_GETGEOMETRY64 didn't exist yet when I did the last updates of SFS, but filesystems don't use any values from TD_GETGEOMETRY anyway, unless LowCyl is 0 like on floppy disks for example, to support both DD (880 KB) and HD (1760 KB) floppies with a single DOSDriver.
On HDs, and anything similar like USB massstorage and NVMe with a RDB, the filesystems only use the values they get in their startup message from dos.library, which are the same CHS values as in the RDB created by MediaToolBox/HDToolBox/HDInstTool/etc.

Quote:How did you check the wrong 1.86TB size? The functions and data structures used by C:Info, the WorkBench, etc. are 32 bit as well and can't display anything > 2 TB correctly.

Quote:Using several partitions <= 2 TB (with 512 bytes/block) should work, but since I never had a HD > 500 GB, and the largest HD the original author of SFS had was only 10 or 20 GB, it could never be tested by a SFS developer.
Please test if it works if you disable diskcache.library in the kicklayout, maybe it's not SFS itself but diskcache.library not working correctly on drives > 2 TB.


@all
The last version of JXFS was intentionally read-only, to let users who used it copy their data to a partition with a working filesystem, without the risk of a JXFS version with write support destroying their data.
In case of JXFS it wasn't a license problem, Hyperion never had any. Beta versions of JXFS were just included as free contributions in some AmigaOS 4.x distributions.
It had too much bugs, and the bugs weren't just implementation bugs, but unfixable design bugs, and since Tony already started working on his better NGFS it didn't make sense to create a 3rd implementation of my JXFS.

@joerg

Quote:
Ah ok. I thought that you were saying that in the context of MediaToolbox. Anyways, a 1-2TB partition doesn't function properly on a >2TB drive. I can copy files and read back from it but the files are corrupted.

Quote:
That is not enrtirely correct. I do see filesystems sending the TD_GETGEOMETRY. Can't didn't watch closely if that is the case for SFS2 as well. But in any case, TD_GETGEOMETRY64 is not used except for mounter.library.

Quote:

Both the WB Disk info window and the WB drive root window top bar show the 3.72TB /xxxMB used correctly in case of NGF\01. In case of SFS2, the same windows shows 1.86TB. Of course I do not know if this is somehow an internal issue between SFS2 and WB which exist for SFS2 and not for NGF\01. But the partition doesn't function correctly anyway. In contrary to 1TB drives or NGF\01. This is at least a hint that somthing is wrong.

Quote:
From what I can tell, it doesn't. But these things happen when you don't have the tools at your disposal to check every corner of your software. I had to solve an issue with TD_GETGEOMETRY as well to make the >2TB drives get recognized correctly. Wouldn't have noticed the bug without having such a drive myself.

@geennaam
Quote:I wrote that the file systems don't use the results from it, not that they don't send the TD_GETGEOMETRY command.
It's used once on startup, but the results aren't used - unless LowCyl is 0. Only in this case the results from TD_GETGEOMETRY are used instead of the data from the file system startup message and additionally the TD_ADDCHANGEINT command is used to get information from the disk driver when a disk is removed from or inserted into the drive. On each disk change TD_GETGEOMETRY is used again to check if there is a disk in the drive or not and if yes use the data from TD_GETGEOMETRY result for the current disk. For example when replacing a DD floppy disk with a HD one in an Amiga floppy drive Sectors/Track changes from 11 to 22 and C*H*S * sector size from 880 KB to 1760 KB.

If LowCyl isn't 0, as it's the case on all partitioned drives, nothing from the TD_GETGEOMETRY result nor TD_ADDCHANGEINT is used but the CHS, etc. values from the file system startup message, the data from the RDB.

@joerg

Quote:

Ok understood. I'll stop looking into it further because I cannot fix SFS2 itself.

@geennaam

Too bad...

Does anyone know how far along NGFS is for non-X5000 machines?

@geennaam
Quote:Did you test it with and without diskcache.library?
If diskcache.library.kmod is installed SFS doesn't do the device I/O itself but just calls the diskache.library functions.
If diskcache.library.kmod is not installed the device I/O is done by SFS.
Would be very strange if the 64 bit device I/O code in SFS, which was implemented by John Hendrikx, has the same bugs for drives larger than 2 TB as the independent 64 bit device I/O code I implemented in diskcache.library.

@joerg

Quote:

Without diskcache of course. I only have SSDs.

But as final test I've also enabled diskcache in my kicklayout. Limit is the same. But at least now I can start the Spencer demo. So the truncated partition is usable.

Now this is really it. Sorry for those who are stuck with sfs2. But I am not going to spend more time on it.

@geennaam
It's strange that it doesn't work for you but does for Raziel
Quote:

Partitioning the disk to two 2048 GB and one with the rest works perfectly fine (two 2 TB and one 1.5 TB partition)

@joerg

Take my comment with a grain of salt...

I didn't do as much testing on the partitions as @geenam did.
i.e. i never copied anything to the partitions, i only created them to see in which size they came up in WB