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

@geennaam
Quote:I don't know anything about the newer SATA hardware and drivers (Sam460, X1000, X5000, A1222), but the old ones, sg2's drivers, and even the IDE scsi.device for classic A1200 and A4000 systems, are limited to LBA48, i.e. 128 PB with 512 bytes/sector.

Quote:Updating MediaToolBox isn't possible, it was implemented by one of the many AmigaOS 4.x developers not payed by Hyperion and who revoked their licences.

In AmigaOS 2 different terms are used for the block size:
BytesPerSector: Hardware/driver block size
BytesPerBlock: FileSystem block size
Sticking to those should make it easier for users to understand which one is referred to as well.

@joerg

I suppose I could monitor the issued commands. Maybe Media Toolbox or format is using TD instead of TD64 commands. I do recall that I saw some in my logs. That would explain a 2TB limit.

@geennaam
I think the problem are the "Last usable cyl." and "Blocks per cyl." values in the RDB. MediaToolBox doesn't have the red dots just for fun
IIRC at least one of the CHS values (Cylinders, Heads/Tracks per Cylinder, Sectors per Track), which are still used in the RDB and in the TD_GetGeometry command even if nothing is using that any more since more than 30 years already but only LBA instead, is only 16 bit.

@Raziel

What happens if you use NTFS as the file system?

@joerg

Changin those two value didn't help. I cut the figures until they were nearly the same size.

@davew

NTFS is not part of the fs i can use, but FAT2 is.
I used that and it comes up in Format as 103G (that is with the whole 6TB).
After formatting the disk is also capped at 2TB giving the handler FAT32 in information

Did you try to convert the partition to GUID?

With MBR patitions are limited to 2TB size, maybe it is the case for RDB also.

@Petrol

How does one do that in MediaToolbox?

@joerg

I now see the red dots where you are referring to. The curious part is that the physical properties are for information only according to Media Toolbox. But they match with a 6TB disk. Could the "for information only" label also mean that Media Toolbox does use total number of sectors instead? This is an unsigned long in struct DriveGeometry. And curiously a large negative value in that screenshot. And the red dots could simply be the result that those positive values are out of range of the negative total number of sectors value?

@all

While i'm at it (slightly OT) i wanted to ask about FS injection in MediaToolbox.

How yould i use NTFS through (i guess) FUSE?

In the *editing partitions* window one could *add, remove or edit filesystems*.
I tried with the stuff i had in l: (where it automatically points to when i click that button) but none are added.

Is that a relic from AmigaOS3.x days or am i doing something wrong?

I tried to add the exFATFileSystem amongst all others, without anything changing in that window, none are added, none gave an error message

Here's my L: dirctory

What about if you enter the dostype of the partition directly in mediatoolbox?
exfat FS dostype seems to be 0x46415458

@Petrol

Then the partition won't come up at all, neither in info, nor on Workbench.

If i start Format from it's drawer it tells me to insert DH1: (which is the partition in question and doesn't show it afterwards obviously)

@Raziel
Quote:Yes, it only supports m68k filesystems.

On AmigaOS 4.x you can only use filesystems on HDs which are kickstart modules.
Filesystems which aren't kickstart modules can only be used after AmigaOS was booted and need to be mounted by something else. For example USB massstorage includes built-in support for that.

As I wrote already SFS is probably limited to 2 TB/partition, and not just the 1 TB mentioned in the readme, with 512 bytes block.
The block numbers inside the partition are 32 bit.
But with 2048 bytes/block it should be 8 TB and using a single partition on your SSD should work. Or in case the limit is 1 TB with 512 bytes/block as mentioned in the readme, because of some old signed calculation not fixed, using 4096 bytes/sector should work.

To test exFAT or NTFS you need to create the partitions with the correct DOSType in MediaToolBox, but the partitions can't mount automatically without the matching filesystem in the kickstart.
MediaToolBox supports saving Mountlists/DOSDrivers for the partitions, you'll have to add the path to the filesystem binary, something like FileSystem=L:exFATFileSystem, to it and put it to DEVS:DOSDrivers.
Not sure, but you may have to disable auto mounting for the partition in MediaToolBox because the partition will be created without filesystem first and overwriting that with the DEVS:DOSDrivers mountlist with a filesystem wont work.

Please post such a mountlist created by MediaToolBox for a single partition using the whole SSD, file system doesn't matter.

@geennaam
AFAIK MediaToolBox mdoesn't use TD_GETGEOMETRY but only the SCSI mode page you have to emualte in your driver.
SFS only uses TD_GETGEOMETRY for removable media with LowCyl=0, for example floppy disk, MO, ZIP, DVD-RAM, DVD+RW, etc. and for that using dg_TotalSectors, i.e. it may still be limited to 2^41 bytes (512 bytes/sector). But for such small removable media it doesn't matter.
On removable media with a RDB, for example USB HDs, LowCyl isn't 0 and TD_GETGEOMETRY isn't used.
If LowCyl isn't 0 SFS uses the data it gets from the filesystem startup message in struct DosEnvec and for example the first sector of the partition is (uint64)de_LowCyl*de_Surfaces*de_SectorPerTrack.

@joerg

Quote:


If Media Toolbox only uses the Scsi mode page commands to request the geometry then we can rule out a driver error.
At least at some point Media Toolbox issues the correct scsi commands:
- read capacity (10) ->opcode 25h
- driver returns logical block address as ffffffffh because the last LBA exceeds 32bit
- read capacity (16) -> opcode 9eh
- driver returns logical block address to the last LBA (64bit value)

The rigid drive geometry parameters page (opcode 04h) is obsolete. So Media Toolbox must calculate its own values for CHS info. And since these add up to 6TB, the correct size has been acquired by Media Toolbox.

Nevertheless, the total number of sectors field is wrong. And this is at least a smoking gun.

@geennaam
The wrong total number of sectors may only be a display problem, and maybe the reason for the red dots as well: C*H*S doesn't match the wrong total sectors.
As long as CHS is correct it can't cause problems since there is no total number of sectors in the RDB.

It doesn't make sense since more than 30 years, but since it was never updated everything on AmigaOS still has to use CHS.
The only AmigaOS part with a LBA value is the struct DriveGeometry result of TD_GETGEOMERY, but since dg_TotalSectors is 32 bit not usable for drives > 2 TB and you have to use (uint64)dg_Cylinders*dg_CylSectors or (uint64)dg_Cylinders*dg_Heads*dg_TrackSectors instead there as well.
Everything in the RDB (devices/hardblocks.h) is CHS:
In the RDSK block rdb_Cylinders, rdb_Sectors (per track/head) and rdb_Heads.
In the PART blocks pb_Environment[] which is struct DosEnvec from dos/filehandler.h: de_Surfaces, de_SectorPerTrack, de_LowCyl and de_HighCyl.
The struct DosEnvec is what the file systems get in their FileSysStartupMsg.

@joerg

I've bought a 4TB NVMe drive which arrived today. Unfortunately, I've ran into the same problem as @Raziel. The disk capacity is shown correctly in MediaToolbox. I can define partitions of > 2TB. But they cannot be formatted. With SFS2, I get a disk is full. With NGFS, I get an uninitialised disk.

Now I was expecting the following sequence from Mediatoolbox:
- Mediatoolbox issues the read capacity (10) SCSI command -> opcode 25h
- driver returns logical block address as ffffffffh because the last LBA exceeds 32bit
- Mediatoolbox issues the read capacity (16) SCSI command -> opcode 9eh
- driver returns logical block address to the last LBA (64bit value)

But this does not happen.

Instead the following happens:
- Mediatoolbox issues the read capacity (10) SCSI command -> opcode 25h
- driver returns logical block address as ffffffffh because the last LBA exceeds 32bit
- Mediatoolbox issues the TD_GETGEOMETRY command
- driver returns struct DriveGeometry

And now things get tricky. Because how to I fill out the 32bit struct DriveGeometry for a >2TB drive?

I can break up the total amount of sectors into C*H*S. But what do I have to do with dg_TotalSectors. Set it to 0?

Anyways, When I do break up the amount of sectors into CHS, I get the correct value for my disk in Mediatoolbox.
But like Raziel, I get those red dots next to "Last usable cyl." and "Blocks per cyl." . When you click on those values with a red dot. The fields to the right give the range (minimum, maximum). When I enter those maximum values, my disk size is reduced to 1.86TB. When I create a partition in this situation, the maximum size is also 1.86TB of course.
Now the format succeeds and the disk is usable.

There's also a TD_GETGEOMETRY64 with a struct DriveGeometry64 defined for the mounter library. Struct DriveGeometry64 doesn't work with CHS but with a 64bit dg_TotalSectors. So I've added support for this command and it's indeed used by the mounter library. But not by MediaToolbox or any filesystem.

So the question is if I am doing something wrong. Or if MediaToolbox is limiting the maximum disk size to 2TB?

EDIT1:
Ok, forget about NGF\01. Apparently I did something wrong (maybe I've selected the old NGF\00)

So I've ignored the red dots in expert mode and defined a 3.72TB partition with SFS2. With a blocksize of 512 bytes, I cannot format and get the "Disk is full" format error.
When I increase the blocksize to 4096 bytes, I can format the drive but the result is only a 1.86TB partition. Further increasing the blocksize doesn't help.
With NGF/01, I can successfully format a 3.72TB Partition. No matter the blocksize.

So MediaToolbox does a lot of weird things with displaying values. It even shows red dots where it shouldn't. But ultimately it's SFS2 which limits the partition size to 1.86TB.

Hopefully we might see NGF\01 for other machines then the X5000 some day, otherwise those systems are limited in partition size.

EDIT2:
SFS2 partitions do not work reliable. Executing something will result in a GR. Not even if I split my 3.7TB into e.g. 3x 1.2TB. NGF\01 works fine in any case.
So it looks that SFS2 will not work with >2TB drives.

I too hope that everyone >X5000 won't be locked out from NGFS...but given the recent developments...i rather doubt it

@Raziel

There's also Jxfs. I do not know the story behind it and why it is obsolete now according to this page: https://wiki.amigaos.net/wiki/JXFS

It still runs just fine on my sam440.

I think you need a pre final edition version because the final edition version is read only

@geennaam

it looks like the partition with jfxs is locked during boot 4.1FE as rw. It can only be ro.
I recently checked this.

https://www.amigans.net/modules/newbb/ ... id=144198#forumpost144198

@smarkusgQuote:

I also did a few tests with the JFXS file system and it is really very fast compared to SFS2, as @geennaam already mentioned it is write-protected, booting the system partition is possible, but you cannot write to this HD.

I don't know why work on JFXS stopped, maybe there were license disputes or developers weren't paid. But it is of course very unfortunate that we cannot use this file system to its full extent.

@Maijestro

Argh...i was about to try this workaround...damn, i need write access to the partition, ro is useless