PFS vs SFS vs FFS - Best Filesystem

[Toni Wilen]

IDE controller: Impossible (for filesystem alone) because normal driver API does not have any support for sending raw IDE commands to the drive. (EDIT: updated driver would be needed that supports trim via SCSI Direct and can translate it to correct raw IDE command)

SCSI controller: SCSI direct can be used but it would also require SCSI to IDE/SD/whatever adapter that also supports trim. (I don't know if any do)

EDIT: Filesystem support (and ignoring driver problems): It should be possible (but really needs full understanding of filesystem logic to implement it properly) but I am still not sure if it is that useful, amount of writes is relatively slow in normal Amiga use. It would also make use of recovery programs impossible.

[BastyCDGS]

Originally Posted by Toni Wilen

IDE controller: Impossible (for filesystem alone) because normal driver API does not have any support for sending raw IDE commands to the drive. (EDIT: updated driver would be needed that supports trim via SCSI Direct and can translate it to correct raw IDE command)

Yeah, I have been completely forgetting that TRIM is only defined in the SATA specs, but not IDE ones (are there even IDE drives supporting TRIM? Not sure just now).

SCSI controller: SCSI direct can be used but it would also require SCSI to IDE/SD/whatever adapter that also supports trim. (I don't know if any do)

They should do, if I can trust the output of hdparm on my Ubuntu system. Although I assume that the kernel translates those SCSI commands to SATA ones internally. But I'm not really sure about that. However, hdparm has a lot of "quirks" command line parameters for problematic controllers.

EDIT: Filesystem support (and ignoring driver problems): It should be possible (but really needs full understanding of filesystem logic to implement it properly) but I am still not sure if it is that useful, amount of writes is relatively slow in normal Amiga use. It would also make use of recovery programs impossible.

Shouldn't be too hard? On formatting, send every block except those required by the FS itself to TRIM handler.
On deleting files, send the freed blocks to the TRIM handler.

I at first thought it could be added in the sense how 64-bit sector addressing was introduced to support drives > 4G.
Ideally, a line "EnableTRIM = 1" in a mountlist could be honored, like "discard" mount option on Linux operating systems in order to force TRIMming...

But: You are right, writes are extremely rare compared to typical modern OS'es. In that sense, implementing TRIM is more a micro-optimization than a real requirement.

[gulliver]

The only way I see TRIM practical for the Amiga is that someone develops in the future some smart hardware interface be it SATA/IDE/SCSI or whatever, that takes care of the wear leveling issue by itself and hides it from the OS.

But then as said before writes are not that frecuent on an Amiga, and developing such hardware may probably be more expensive and time consuming than just replacing your storage media.

Maybe connecting a raspberry pi to an Amiga using its GPIO pins and using some networking filesystem might do the trick, and be affordable enough at the same time. Yet, it remains to be seen.

My advice for a safe and long amiga journey, regardless the type of media, is to back up twice a year, and change storage media for newer ones each 10 years. That said, you should back up more often if you use it fequently for content creation, but that is certainly not the case for most users, that only customize their workbench and play whdload games.

[amiwolf]

Originally Posted by Toni Wilen

I'd like to have some real world proof that makes it worth the trouble..

It is very useful (almost required) when using very slow media like floppies or CDROMs but I am not sure if it makes any noticeably difference when used with harddrives.

EDIT: AFAIK OFS/FFS has always been multi-tasking friendly (disk operations don't stall packets that don't need to access the disk)

Thank you for your reply, Toni. Always good to hear an informed opinion.

[BastyCDGS]

Originally Posted by gulliver

The only way I see TRIM practical for the Amiga is that someone develops in the future some smart hardware interface be it SATA/IDE/SCSI or whatever, that takes care of the wear leveling issue by itself and hides it from the OS.

This would require that this hardware is aware of every filesystem on the Amiga. The problem with wear leveling is that the controller needs to know which blocks are unused by the filesystem in order to recognize as free for use.

Basically, we need something like a tool which is capable of sending TRIM commands with the contents of every unused block by the filesystem.

Maybe it can be handled like TD64/NSD was added to the Amiga. We should just ensure that no one already has declared a definition for TRIM command (OS4.x+ devs maybe or AROS could have be something already regarding to it) in order to avoid two or more concurrent definitions.

But then as said before writes are not that frecuent on an Amiga, and developing such hardware may probably be more expensive and time consuming than just replacing your storage media.

I would even be happy with a simple command line tool like "fstrim" on Linux which simply sends all blocks marked as free to use to the drive.

EDIT: Has someone ported FUSE to Amiga? If yes, a lot of alternative file systems could be easily usable on Amiga (including NTFS, EXFAT and even ZFS could be possible).

[klx300r]

I've got a 25 GB partition on a DOM (disk on module) in my A4000 I would like to use PFS3AIO on and was wondering what block size and buffers to put in HDToolBox parameters?

[paul1981]

The standard (default) settings should suffice in most cases.

[klx300r]

Originally Posted by paul1981

The standard (default) settings should suffice in most cases.

when adding PFSaio to OS3.1.4 HDToolBox a requester pops up asking with following 'default values'

Enter DataType for File System:0x444FS5303
Enter version: 19

enter revision: 2


when hitting ok it says file system already exists...it appears default setting for this screen is same as FFS ? quick Yahoo search and I see figure should 0x50465303 but would love to have this confirmed as I want to get this right the 1st time and not go through deleting/ reformatting stuff afterwards...same goes with block size/ buffers

[gulliver]

DosTypes:

0x50445303 PDS3 Professional File System AIO
0x444F5303 DOS3 International Mode FFS
0x444F5307 DOS7 Long Filename FFS

If it is flash media you are using I would suggest a block size of 4096. As for buffers it depends a lot. Better ask Toni about that. But I am sure he set a safe number as default.

[klx300r]

@ gulliver

thanks for the info on 2nd screen now and should I keep Mask default 0x7FFFFFFE & Max Transfer 0XFFFFFF ??

for buffers I can wait since you can change that any time I believe without losing any info on partition

[Leander]

Originally Posted by klx300r

@ gulliver

thanks for the info on 2nd screen now and should I keep Mask default 0x7FFFFFFE & Max Transfer 0XFFFFFF ??

for buffers I can wait since you can change that any time I believe without losing any info on partition

Hi klx300r, i don't know if in your case (i seem to understand we talk about real HD?) you have to leave Max Transfer at its default value.
Personally for my CF (4GB and 8GB too) i have to set Max Transfer parameter to 0x1FE00, else whdload games copied inside there expecially on a real Amiga, won't work (read/write error messages or similar), so you could leave default value, make a quick try copying and running some whdload stuff and if you have issues change this parameter.

[Leander]

On a side note, if like i suppose you use HDInstTools for partitions (and I also believe HDToolBox) and you change the Max Transfer you should not lose the content of the partition, even if both programs being saved warn you that any change will result in data loss
So if you have issue with default parameter and then change the Max Transfer after copying the data you should not lose them, but for safety I tell you to copy a few, do all tests you need, see what happens and then take your decision

[klx300r]

@ Leander


great advice and makes sense & yes it's real Amiga 4000 and real HD

[Leander]

Originally Posted by klx300r

@ Leander


great advice and makes sense & yes it's real Amiga 4000 and real HD

You're welcome mate!

[nikosidis]

I see some strange advice here. Why are people recommending FFS? It is nothing close to SFS or PFS3. &lt;br /&gt;<br />
The great thing about PFS3 is that it work with with any Amiga while SFS require at least 020.&lt;br /&gt;<br />
FFS have the known forever validation error on real Amigas, is very slow and not reliable.&lt;br /&gt;<br />
I would never use FFS for my system partition. That is the partition you should not use it.&lt;br /&gt;<br />
PFS3 I never had a single problem with. That is using my Amiga almost every day.<br />
<br />
Installing PFS3 on real amiga boot from Amiga911.adf I can put it in the zone if you like. I have used it for my A1200 and A600 without problems. I have 3 partitions. System partition is around 4GB and other partitions are 7GB and 3GB. OS is 3.1

[paul1981]

Originally Posted by klx300r

when adding PFSaio to OS3.1.4 HDToolBox a requester pops up asking with following 'default values'&lt;br /&gt;<br />
&lt;br /&gt;<br />
Enter DataType for File System:0x444FS5303&lt;br /&gt;<br />
Enter version: 19&lt;br /&gt;<br />
&lt;br /&gt;<br />
enter revision: 2&lt;br /&gt;<br />
&lt;br /&gt;<br />
&lt;br /&gt;<br />
when hitting ok it says file system already exists...it appears default setting for this screen is same as FFS ? quick Yahoo search and I see figure should 0x50465303 but would love to have this confirmed as I want to get this right the 1st time and not go through deleting/ reformatting stuff afterwards...same goes with block size/ buffers

Regarding the buffers, set to 300 if you have the full WHDLoad games set installed, but only for the drive that the games are stored on. If you have a seperate boot drive, 70 buffers or less will be fine for the boot (70 was the old PFS minimum setting, so stick with 70 to be safe; although now with the later versions it's supposed to be safe to use any figure below 70).

[klx300r]

thanks for the help guys..it seems my 25GB partition is working fine but did notice when creating a new folder in DOpus that a popup occasionally appears saying' An error occurred adding an icon to "name of folder" DOS error code 217-Too many levels"..I just hit skip the few times it happened and everything seems ok but to be sure I ran PFSDoctor and it took a very loooong time searching for an index block and right now as I'm typing this it finally started to slowly start "Building indexblock"...so fingers crossed this might take am few hours ....


wondering if this happened because I formatted the partition under OS3.1.4 as I didn't know about PFSDoctor and PFSformat before?

[Thomas Richter]

Originally Posted by nikosidis

I see some strange advice here. Why are people recommending FFS?

It's working and maintained. Unlike SFS, for example, which is not maintained, and it is the file system that comes with the system.

Originally Posted by nikosidis

FFS have the known forever validation error on real Amigas, is very slow and not reliable.

I doubt the "slow" part. Actually, data transfer can hardly be any faster than with FFS. Goes directly from the disk to RAM (or reverse), without additional buffering. Finding/locating files with FFS is also fast (one hash, one block to be read). The only part that is slow in FFS is listing directories. In fact, unlike SFS, FFS is fully multi-threaded, so while the disk is busy accessing sectors, FFS is able to retrieve additonal commands. I am not sure about PFS, but SFS is not and uses a slower two-level design, so every operation has to go through three processes by message ping-pong.



Only with 3.1.4, the two other file systems (crossdos and cdfs) became fully multithreaded and thus won't slow you down either by waiting for I/O.


A typical case where that matters if one application reads/writes a file, and at the same time you open a workbench window. With a single-threaded system, you would have to wait until the read/write operation is over to allow workbench to react. With FFS (and the new file systems), workbench can serve the icon data in parallel if it is in cache.

Originally Posted by nikosidis

PFS3 I never had a single problem with. That is using my Amiga almost every day.

We found during testing that PFS has problems with recursive directory deletion and throws sporadic errors. I'm using FFS ony my Amiga almost every day without problems either...


Thus said, I'm not trying to tell you that FFS is modern, has a great design and the best file system ever created. Certainly not. But it is neither as bad as you try to make it. It is working, well supported, comes with a recovery tool, and is the file system that defines the standard on the Amiga. Probably on a low level, but still - it works.

[meynaf]

Originally Posted by Thomas Richter

The only part that is slow in FFS is listing directories.

For listing directories there is the dircache option. Seems only useful for floppies, on HD i didn't notice it being really slow.

However there is also seeking in large files. Painfully slow. You can offset it with large buffers, but nevertheless.

[Radertified]

Is it possible to download the latest incarnation of FFS from Aminet (or elsewhere) or is it bundled with Workbench?

I would love to be able to use an updated FFS on older machines (WB 3.0 and below) that either don't match WB 3.1.4 specs or I don't want to update to 3.1.4.

The great thing about PFS is it's free and easily installable on all specs. Would love this to be the case with FFS!