How big (I mean Gigabytes/Terabytes) can be partition under AmigaOS4.1? and how big hard drive itself (also in Ggabytes/Terabytes). If Mortherbroad is important thing its Pegasos 2 with G3/600Mhz.

@Vanhapolle

Filesystem is the important part.

Quote:

FFS2 supports 2^32 block per partition at 512 per block that makes 2Tb at 32768 per block 128Tb File size is limited to 2^31 (2gb)

Source

Perhaps there are more answers for you in the same thread. At least it is fairly current.

#6

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

@number6

Yes filesystem is important i forgotted say most modern which comes with AmigaOS4.1 installation stuff.. i think its JXFS?
ps. means text which you refer 2 Terabytes partions and whole harddrive is 128Tb?

@Vanhapolle

No the text refered to, means when the *blocksize* is 512 the the max partition size is 2 Terabytes.

Increasing the blocksize increases the maximum partition size in proportion.

This only applies to FFS as the other file systems have a fixed blocksize of 512 but can access larger partitions due to different design,

Use SFS or SFS2 for best results on AmigaOS 4 for the moment. SFS2 if you need largefile support.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@broadblues

I want know if SFS and SFS2 are free or bundled with AmigaOS4.1? actually i think real suppored things etc info for AmigaOS4.1 is not so easy found.

@Vanhapolle

You get FFS2, SFS and JXFS with the OS. All are there and ready to be used.

JXFS is not recommended any more.

Most people use SFS because it is fast and reliable, but a partition with errors can not be repaired and has to be reformatted. SFS is limited to 512-byte blocks.

FFS is slow and reliable, but a partition with errors will usually fix itself and there are tools for checking/repairing it. FFS can support blocks of any size up to 32768 bytes.

_________________
cheers
tony

Hyperion Support Forum: http://forum.hyperion-entertainment.biz/index.php

@tonyw

FFS sounds my solution i bet its suitable fast. I very likely use AmigaOS4.1 more coding than anything else if i found nice tools. And few graphic programs if they works few old Photogenics versions,and Personal Paint. And looking what is available...

@tonyw

You mean when wrote FFS old one or this FFS2?

@Vanhapolle

There is no "old one". FFS in OS4 is FFS2.

_________________
Email: thomas-rapp@web.de
Home: thomas-rapp.homepage.t-online.de

@thomas

There used to be some thing called OFS, I belive.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@thomas

if its also reads old HDs with FFS sounds really good.

@Vanhapolle,

It will "read" anything but if you "copy" it over it will be what you set it.

@Vanhapolle

Don't be fooled by the name in FFS (FastFileSystem). It is very slow (by a factor of 10 compared to SFS or JXFS), and since it is not journalizing it is not reliable and breaks very often. However, it often fixes itself the next reboot (it has to since it breaks so often), but that takes a long time (could be hours on big partitions).

SFS and JXFS never breaks because of crashes or lockups. SFS and JXFS also has a built-in undelete function for several revisions of deleted or overwritten files. If you accidently delete or overwrite a file on FFS it will be gone and you need a repair tool to scan the disk to maybe get your file back. With SFS or JXFS you simply go into ".recycled" and pick your file.

Only down-side of SFS and JXFS (which the crazy FFS fanboys scream about ) is that there is no repair tool. But on the other hand, you don't need one I have used AFS, PFS2, PFS3, SFS, SFS2, JXFS (they are all similar) for 15 years (which is when I abandoned FFS) and I have never been in the need for any repair tool and I have never lost any files.

Of course: ALWAYS have backups of your data, no matter what file system you use

And to answer our question:
SFS has a 128GB partition size limit and a 4GB filesize limit.
SFS2 and JXFS supports larger partitions and more than 4GB files (up to the partition size I suppose). I think JXFS only supports 1TB partitions.
All these file systems use 512kB block size, but MediaToolbox defaults to 1024. Beware!

Note that these limits are not enforced! You can create a 500GB SFS partition, but it will just be trash, and could trash other partitions as well. JXFS does not stop you from creating a 2TB partition, but it will not work.

Last edited by Deniil715 on 27-Sep-2014 at 08:22 PM.

_________________
- Don't get fooled by my avatar, I'm not like that (anymore, mostly... maybe only sometimes)
> Amiga Classic and OS4 developer for OnyxSoft.

@Deniil715

Good info. and at least my MorphOS1.4.5 SFS never gived problems. Seems relaative reliable i used abot 10 years ago most of my time this MorphOS system. Btw i bet is 11th month when i have stuff what i need use AOS4.1.

@Deniil715

Quote:

All these file systems use 512kB block size,

Sorry to be picky, but I think you mean "512 B", not 512 kB".

Apart from that, I agree with everything you say. I use JXFS on all my non-booting partitions and the only time I have had problems is after hardware failures.

_________________
cheers
tony

Hyperion Support Forum: http://forum.hyperion-entertainment.biz/index.php

@tonyw

Quote:

Sorry to be picky, but I think you mean "512 B", not 512 kB".

Of course, of course!

And yes, only hardware (or driver) failures destroy the journalizing file systems. FFS dies just by rebooting while having a file open for writing. FFS then repairs itself, if it can. I have seen SFS and JXFS discover an abandoned operation on a reboot as well after a bad crash. It just closes the transaction and notes the user and that's it.


Once upon a time I betatested the FastATA.driver for 120GB+ disks. At this time I was using PFS3 and the driver actually caused random bit-errors to be spread all over all partitions; inside files, in directory names and structures - everywhere. PFS3 survived with only 3 lost file (and of course a few bit errors in many files). At the time I also had an FFS partition which I didn't use much. That whole FFS partition quickly became completely useless and eventually disappeared from the disk! The PFS3 partitions survived. And now the FastATA can handle 120GB+ drives

_________________
- Don't get fooled by my avatar, I'm not like that (anymore, mostly... maybe only sometimes)
> Amiga Classic and OS4 developer for OnyxSoft.

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @thomas There used to be some thing called OFS, I belive.

The file system which shipped with the original Amiga back in 1986 was later referred to as "OFS", to make a distinction between the "FFS" as introduced by Workbench 1.3 in 1987. The "FFS" was designed for use with hard disk drives, which the "OFS" was poorly suited for.

This is still the case. If I remember correctly, OFS partitions using the Amiga file system of the time, could not be significantly larger than about 40-50 MBytes due a bug.

The modern FFS reimplementation which is available for both AmigaOS4 and MorphOS should allow for larger OFS partitions, but you will instantly regret using those.

OFS is not made for large media and best used on floppy disks.

@olsen

An extra note WRT FFS2, I formatted a USB stcik with FFS2 for an experimental reason last night, it took 3 hours to copy 50Mb of data! Admittedly it was a slow stick for writes but SFS copied in minutes. So if anyone is tempted make a USB with amiga file system choose sfs!

Last edited by broadblues on 28-Sep-2014 at 05:27 PM.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@broadblues

Good tip. Or amazing.

@broadblues

Quote:

broadblues wrote: @olsen An extra note WRT FFS2, I formatted a USB stcik with FFS2 for an experimental reason last night, it took 3 hours to copy 50Mb of data! Admittedly it was a slow stick for writes but SFS copied in minutes. So if anyone is tempted make a USB with amiga file system choose sfs!

SFS is a journaling file system, which in this context means that it can queue a number of operations which change the bookkeeping information ("metadata") of the file system (directories, files, their names, the sizes of files, which blocks will be used for storing newly-added data) and then make these changes in one single step. Should the operation get interrupted, the file system can just repeat these queued changes when it is restarted later.

The FFS cannot do that. Each change that has to be made to the metadata blocks needs to be done quickly, if not immediately. An additional complication comes in because the on-disk data structures cannot be safely changed immediately, because they were not designed to be safely changed. This means that if you reboot your Amiga or crash the file system while a write operation is not complete, it will leave the file system in an inconsistent state which requires manual repair.

I rewrote the FFS from scratch, back in 2001, and one of the changes I made to the behaviour of the file system involved reordering the on-disk data structure modifications that are made when data is written to disk. By reordering these operations the risk of leaving the file system in a damaged state, should the entire write operation be interrupted, is greatly reduced, compared to how the original FFS used to work.

But I also changed something else, and this is what makes writing slower than with the original FFS: each individual on-disk data structure change that is performed during a write operation is immediately committed to disk. As data is written to a file, the file system has to update and rewrite several blocks over and over again, and each update concludes by telling the storage driver to push the changes to the storage medium.

These changes, which make writing slower, also reduce the chance of leaving the file system in a damaged state, should the write operation be interrupted.

If you are certain that you can do without the extra bit of robustness which these changes trade for speed, you can turn back the clock and make the new FFS handle write access like the original FFS. There is a command called "fs_set_flush_strategy" which can be used to switch between the old and new behaviour.

For example, "fs_set_flush_strategy hd0: 1" will make the file system delay committing metadata changes to disk, operating like the original FFS, and "fs_set_flush_strategy hd0: 0" will make the file system commit metadata changes immediately (which is the default behaviour).