SFS2 still unable to format big partitions ???

As per its documentation, SFS2 support really BIG partitions (way bigger than 2 TB).

per example, a 3 TB disk with a 2048 GB SFS2 partition is formated fine by both SFSFormat and sys:system/format.

But the same 3 TB drive with a full 2760 GB SFS2 partition is formated by the same softs as... 730 GB !

and a 4 TB disk with a full 3726 GB SFS2 partition is shrink-formated by the same as... 1678 GB !

for a filesystem meant to cope with "petabytes" partitions (perhaps I exagerate a little ;)) is disapointing at least :(

so, questions to the maintainer of SFS2 :
- what's the problem ?
- will an updated sfsformat will suffice to have that BIG partitions (FULL SIZE 3 and 4 TB disks partitions) formated to the right size ?
- where to find the SFS2 sources to work on it ?

@voxel

iirc there was an sfs2 update within the enhancer package, so the sources seem to be secured by AmigaKit

@voxel

You already posted these details to the seon bugtracker, the author is assigned to that "product" so should be aware.

@voxel

Quote:How did you check it's not working correctly?
Please note that there are some limits in OS structures and tools a file system can't fix, for example the number of total blocks on a partition returned in the DiskInfo id_NumBlocks is a 32 bit value and therefore limited to about 2 TB ((2^32-1)*512 bytes/block). It's the same for the number of free blocks, which will be displayed wrong as well as long as more than 2 TB are free (with 512 bytes/block), and with both wrong the percentage of used/free space on a partition can't be displayed correctly either.
Using larger block sizes may "work" (1024 bytes/block -> 4 TB, 2048 -> 8 TB, ..., 32768 -> 128 TB), but only for displaying the size in some external tools, the Workbench, etc., it wont make any difference to the correct 64 bit sizes used inside the file system itself, and unlike for example FFS SFS gets slower with larger block sizes and therefore larger block sizes shouldn't be used. The tools which display the size have to use 64 bit calculations internally or it still wont work, with 32 bit calculations probably still used by a lot of tools you'll get an overflow and wrong sizes displayed even when using larger block sizes.

Quote:No, formatting is done inside file systems.

Quote:On my HDs and backups It's not open source.

@joerg

Pls note, that the following is not meant as trolling.

What do you think: why people are telling you, that there is something working not correctly? Do you think they just "imagine" problems because they don´t have deep knowledge of the internal workings of your product?

I want to tell you, that you should take such reports more serious. The average user just sees what the SFS tools are telling him. If the output is plain wrong, it would be a better solution to repair or expand or fix those tools instead of telling stories about "hey, the tools are printing out plain BS, but in the background all things work ok, and it´s not my fault that things are like they are".

@whose

You clearly either didn't read his reply properly or failed to undertsand it.

The first part of the response was "How did you check it's not working correctly?"

The response to that is not 'I'm not trolling honest' and 'do you think I'm imagining this?' but to answer the question.


If the problem really is that tools (such as INFO and Workbench) use 32bit values to display number of blocks and hence calculate the partition size incorrectly thats an OS bug and not in his scope of responsibilty.

@joerg ^^)

please see the answer on the a-eon mantis bugtracker report I made as there is some betatesters/dev only stuff in it ^^)

@broadblues

what I can say is that info and format have no problems to report the right 3760 GB size of the partition.

@voxel

If C:Info reports the right size then it might well be formatted correctly?

What is the actual output of C:info ?

@broadblues

oups! sorry I forgot say "formated under another new filesystem than SFS2"

@voxel

Quote:

With a larger block size as well I bet.

With block size of 512 bytes id_NumBlocks overflows at >= 2TB.

@broadblues

I understand quite well. Voxel statet, which tools he used to format (and to show) the partitions. One of those tools is sfsformat. So, the essence of joerg´s answer is: "you didn´t use the right tools. All is working fine, under the hood. It´s all about outdated software using 32 bit integers".

At least sfsformat should print out correct values, if used on SFS2 partitions.

@whose

It is only a display/cosmetic issue. Whether you use sfsformat or the default format command (for a quick format) all it does is send an ACTION_FORMAT packet to the file system which does the actual work.

@whose

SFSformat doesn't print out any value, so clearly can't print out the wrong (or right) value

I think voxels point about Format V SFSFormat was that they both behaved the same in appearing not to format the partition correctly.

@broadblues

Nice that SFS2 is still being worked on

Ok, so now i'm not completly OT and knowing the PM notification on this site is really bad...

you got PM