Anyone working on PFS3 ??

[Piru]

Just wondering if anyone is working on PFS3 to enable big TB partitions.

Enabling larger partitions is a bit tricky. There are some notes about it here:
http://sourceforge.net/tracker/?func=detail&aid=3285711&group_id=532591&atid=2163218 (click comment)

See here for the full list of feature requests:
http://sourceforge.net/tracker/?group_id=532591&atid=2163218

As for the progress: PowerPC native PFS3 is working on MorphOS now.

[Piru]

If you're really looking to work with TB sized partitions the I'd recommend SmartFileSystem as there is no limitation on partition size or HD size.

SFS is dog slow compared to PFS3 though. Also there for sure is a limitation of 2TB, so there's no use in getting a HDD larger than that.

[Piru]

Slow is just your opinion Piru and of course your entitled to that.

Actually it isn't an opinion but fact that can be verified by anyone.

But you are very wrong in saying that is has a 2TB limitation

The limitation is 2TB.

[Piru]

From what i've read, the source code that was released is for version 18.3.

There was an important bugfix in 18.5 that is needed for Apache to work. Is that fix existing in the source code at sourceforge.net?

See http://sourceforge.net/tracker/?func=detail&aid=3285730&group_id=532591&atid=2163218

The filesystem itself should be pretty much in par with 18.5 now, except that it's actually even better (several serious bugs have been fixed).

[Piru]

RDB can only handle 32bit sector numbers. Unless if we ditch RDB for GPT (or similar) we're limited to 2TB disks.

In addition TD_GETGEOMETRY is limited to 32bit sector count:

Code: [Select]

       ULONG dg_TotalSectors;    /* total # of sectors on drive */
There's nothing a filesystem can do about this. And before anyone asks, no, adjusting your block size for the filesystem will not help here.

[Piru]

Piru: Are there any advantages to me updating my MorphOS partitions to PFS over the default file system that MorphOS uses during an install?

Assuming your HDD uses RDB and it's thus possible to use PFS3...

Yes. Even the 68k PFS3 is a lot faster than SFS.

Later on PFS3 will be included in MorphOS itself, too.

[Piru]

And in this case anyone can easily download SmartFileSystem from the link I gave and test it for themselves to see that no matter what Piru says on this subject he is just simply wrong...

Tell me, how many >2TB hard disks have you partitioned with an amiga?

[Piru]

So, where exactly can I download a nice precompiled and user-friendly release of this new open-source version?

Nowhere as of yet. For now you should use the PFS3 binary version uploaded to aminet.

If you really MUST have the latest goodies you need to build it by yourself. For 68k version you need SAS/C and the amiga NDK 3.x. You also need to install the multiuser.library SDK if you wish to build the multiuser version.

However I'd advice against using the development PFS3 version in a production environment. Things can be in a slight flux there.

[Piru]

Now you tell me after you've given SFS Ver 1.279 a try on an Amiga that it has a 2TB limitation...

I don't need to test it. I know it's technically impossible to partition a >2TB drive reporting 512 byte block size (that's what current drives do due to compatibility reasons). These drives will report more than 2^32-1 sectors and you cannot fit such number into 32bit data type (used by both TD_GETGEOMETRY and RDB itself).

[Piru]

Wrong... yet again... no one said anything about using 512 byte block sizes...

You cannot change the block size the drive uses internally. Logical block size used with filesystem is irrelevant here.

Do us both a favour go read the docs

Any amount of reading the docs won't change the fact that it's impossible to RDB partition a >2TB drive reporting 512 byte block size. If the documentation claims otherwise it is in error. You do realize that the documentation might not be entirely accurate?

send you theories to the author of SFS

The real author of SFS is doing some other things these days. For some reason the project was hijacked by this strohmayer guy. Regardless, both would agree with my assessment. As will anyone who can understand simple math.

[Piru]

you can post all the technical mumbo jumbo you want

It actually is quite relevant technical information that explains in simple terms why I am right. You can of course try to deny it all you want, but it still doesn't change the facts presented.

You on the other hand seem to base your claim on the dubious remarks in the documentation: "Supports large partitions.  The limit is about 2000 GB, but it can be more depending on the blocksize." and "With this new 'SFS\2' format it's possible to create ... partitions larger than 128 GB (the limit for 'SFS\2' partitions is 1 TB * blocksize / 512)."

What the author of that comment doesn't realize is that while the FS might in theory work with larger block size, there is no way to partition >2TB HDD by using RDB. In fact there isn't even a way to query the true capacity of such drive via TD_GETGEOMETRY.

Thus the maximum is in fact limited to 2TB, regardless of the logical block size you might use.

[Piru]

prove

• TD_GETGEOMETRY and RDB use 32bit unsigned value to store block numbers. The maximum block number they can represent is 2^32 -1 or 4294967295.
• 3TB HDD uses block size of 512(*). The capacity reported is around 3 * 1000 * 1000 * 1000 * 1000 / 512 blocks or 5859375000.
• The value 5859375000 is larger than 4294967295. Thus it cannot be represented with a 32bit unsigned integer data type. Ergo TD_GETMEOMETRY or RDB cannot properly report/handle such device.

(*) Internally these drives use 4KB block size, but due to compatibility reasons they report back 512 byte block size.

[Piru]

A minute ago you were telling me you the author would agree with your assessment

He still will. Unless if he's stupid enough not to see the problem.

now you've read his docs you are now telling what he says is dubious...

The claim is misleading. The author doesn't realize or doesn't want to acknowledge that there are limits imposed from elsewhere.

you go ahead and try it on a >2TB HD and if it doesn't work then I'll happily admit I was wrong

I tell you again: There's no need to test it, it will fail at partitioning time.

[Piru]

@Franko

You asked for proof and I provided it. Care to explain how my proof is incorrect?

[Piru]

The only problems you will encounter are application displaying the wrong file size as most were written never expecting to take files of >4GB into account...

With AmigaOS 3.x that would be all applications. APIs in AmigaOS 3.x can only represent a 32bit number for the file size.

Only applications reading up until EOF will work properly. Any AmigaOS 3.x application that actually queries the file size first before processing that amount of data will fail. Many applications seeking in a file will fail randomly as negative return value from Seek() was commonly considered an error.

Oh I'm sorry for giving you more technically correct and factual information. You may yell "YOU'RE WRONG!" if that makes you feel any better.