It is extremely simple to write an FS implementation, so long as kept logical and simple. This is a problem when you want to try to provide a certain set of features, and want to also make the filesystem simple and efficient. Sometimes something being easy is a problem, and this is one of those cases. This refers to the FS drivers, not the block device drivers (which are separate).

The issue is that it is easy to end up redesigning the FS on disk structure, and implementing each one to test it. In the end you end up writing a great number of different filesystems, each different, each accomplishing the same goals. In the case of YFS I have implemented 15 different Filesystems so far, each of which accomplishes all the needed goals for what is needed, each of which is efficient and simple in design. And I have finally had to tell myself that if I keep it up there will not be a long term compatible FS that is simple enough to be usable for extreme long term computing, so I need to pick one and stick with it without changing the on disk structure. Thankfully the API for using the FS has never changed among all these changes (at the low level it is an AmigaDOS like API (extended to handle multiple stream files), at the OS level its API is determined by the API of the Operating systems being cloned).

So it is that some things being too easy to accomplish can make these things more difficult. The FS is not the only place this issue has popped up in the development of YASDOE, though it is a big one.

Ironically it is helpful that it is easy to test new filesystems on RISC OS, as implementing an ImageFS for each is quite simple, and thus can test with an image file of the filesystem.

A very simple solution is to use slightly updated versions of existing filesystems. The two primary filesystems are a version of ADFS with the name field extended to 31 characters, though otherwise like classic 10 char name ADFS, and Amiga FFS with a special file in each directory that contains the filetypes in a hash indexed table (using the same hash algorithm as is used for file entries on Amiga FFS).

The Amiga FFS with extension is the preferred filesystem for what should be obvious reasons. The features of FFS make it a bit more robust than ADFS in most use cases. Also file lookup time is greatly reduced by the structure of FFS.

The extension of ADFS was chosen as it is just as incompatible with the older ADFS as is the method used by RISC OS 4/6 and 5 for supporting long file names, and it is more robust than the method used in newer RISC OS implementations. That said it is entirely intended to support the traditional 10 character ADFS implementations and have some level of support for the newer versions. Our extension also does provide some of the enhancements to better handle larger volume sizes without the allocation unit size (think cluster) getting to large (currently only up to 2TB without exceeding an 8KB allocation unit size).

There is also a version of the ADFS FS implementation that does work with the older 10 character filenaming, though uses the method used by LongFiles to support files with names longer than 10 characters when needed. This works fairly well, as the majority of filenames are under 10 characters anyway.

Both ADFS and FFS are designed in such a way as to greatly limit file fragmentation, which was a big part of the decision. It is better to avoid fragmentation as much as possible than it is to have to defragment files more often. In both FS implementations when files become fragmented the FS drivers attempt to cause the file to be defragmented by moving it as needed, thus limiting the need for explicit defragmentation.

For a strange side of things there is also a unique filesystem included. This is a filesystem that was developed for use with YASDOE originally, though has a few disadvantages over FFS or ADFS (mostly that it is not readable by any other OS yet). So the final version of YFS is included in the OS, though it is recommended not to use this FS.