Native support for ext3fs, reiserfs, XFS and ZFS

Hi!

I would really like to see native (non-imagefs) support for some common unix filesystems like XFS, ext3fs, reiserfs and ZFS, plus vfat. I realise that this will most likely only happen if we use GPLed code from the Linux kernel, but I don’t see a problem with that if it was implemented as a separate module. The way I see it, everyone can decide for themselves, if they want to include it in their ROM image, or soft-load it later or not use it at all. But I suspect that the reliance on the rather limited ADFS (both in performance and in features) is preventing the use of RISC OS in many possible applications. It would be a nice option for OEMs who don’t mind a GPLed module, and very useful for desktop users which have to exchange data with Linux, MacOS, Solaris, Irix or Windows.

If by VFAT, you mean long filenames on FAT discs, we already have that, at least in RISC OS 5.

The problem with GPL-licenced filing systems is that they’re exactly the sort of thing that needs to be in the ROM, because otherwise you wouldn’t be able to boot from a disc that used that filing system.

However, one of the filing systems you mentioned, ZFS, is not GPL. It is licenced under the CDDL, a variant of the MPL, and is therefore much less of a problem to include in a released ROM image.

If by VFAT, you mean long filenames on FAT discs, we already have that, at least in RISC OS 5.

Yes, but IIRC it is implemented as an image filing system, right? Wich means that the partition size is limited to the max file size of RISC OS. AFAIK the VFAT FS of Linux also supports FAT32 partitions.

The problem with GPL-licenced filing systems is that they’re exactly the sort of thing that needs to be in the ROM, because otherwise you wouldn’t be able to boot from a disc that used that filing system.

So people could easily include the module in their own, personalised ROM image if they want to boot from such a filesystem.

However, one of the filing systems you mentioned, ZFS, is not GPL. It is licenced under the CDDL, a variant of the MPL, and is therefore much less of a problem to include in a released ROM image.

And of course is also the reason why Linux folks are so upset regarding ZFS. It simply put is much better than anything Linux has to offer (including XFS), the source is available, but because it is not GPL, they can’t use it in their kernel. Meanwhile OpenSolaris integrates more GPL code each day. But Sun has already hinted that they are looking into releasing ZFS under the GPL as well.

Anyway, I think it would be nice to have ZFS as the new default filesystem in RISC OS (included in standard ROM images) and the other ones as disc-based components included in !Boot.

ImageFSs aren’t the problem (they’re a huge asset), it’s their 32bit interface which is the problem. However, there’s no reason why it couldn’t be extended to 64bits, selected by a bit in the ImageFS information word. At which point, the entry point args become:

ImageEntry_Open
...
<= R3,4 = file extent
   R5,6 = number of buffers

ImageEntry_GetBytes
...
=> R4,5 = offset

ImageEntry_PutBytes
...
=> R4,5 = offset

ImageEntry_Args,3
R2,3=file extent

etc.

Note, I don’t think ImageEntry_File,7 needs extending, as it’s an analogue of save, so memory bound – creating a BIG file would require ImageEntry_Args,3 to set the 64bit length. All of this assumes a 64bit Filecore, naturally.

Having such FSs implemented as Images is hugely advantageous. It would be a real shame to lose the nesting flexibility.

[paraphrase: “ZFS is great / and presents no legal problems to incorporate in ROM image”]

OK, so this all sounds good. Is replacing the ADFS format with ZFS a feasible option? Is it worth making it some kind of formal goal? Are there any such goals?

Adam