Möbius File System

Tim Robinson

1.Introduction

This document describes the requirements for a native file system on the Möbius Operating System and details some thoughts on the practicality of using pre-designed file systems for the Möbius system. A future revision may include technical details on a proposed new Möbius File System format.

The native Möbius file system will be the ideal format used by the OS. Every operating system has one of these, although a good OS should be able to access (and ideally write to) a wide variety of foreign file systems. In most cases a file system was developed alongside the operating system itself.

Although it is desirable to use another established file system format for The Möbius (both for the sake of interoperability and to make development easier), it is more important to have a native format which provides the necessary features without compromise.

2.Requirements

Any file system for Möbius should offer the following features:

• Long file names (> 64 characters) with a wide range of valid characters
• File names stored in a Unicode-compatible format (e.g. UTF-8 or UCS-2)
• Ability to store MIME type and ACL information alongside the file
• Good extensibility for future expansion
• 64-bit pointers and sizes
• Ability to keep multiple versions of a single file (versioning)
• Reliablility

The following features are desirable:

• Journalling
• Inodes/file records
• Use of extents rather than block numbers in the inode
• Access to arbitrary named attributes/alternate data streams
• Ability to store data for short files directly in the inode
• Compression
• Indexing
• Speed

3.Other File Systems

FAT:The FAT file system is included in here for completeness, and because it is currently the only file system that The Möbius can write to. It lacks almost all of the requirements above.

ext2:ext2 is the native Linux file system and is reasonably mature and well-established. It has a reputation as a fast but unreliable file system, although this stems mainly from the Linux implementation, which caches most file data and metadata, keeping disk access to a minimum. In its most basic form, it supports most of the requirements. However:

• It lacks support for filenames in characters sets other than ISO-Latin-1
• Versioning could be implemented as multiple inodes which differ by their version number (which could be recorded in one of the reserved fields), referred to by directory entries with the same name. However, it is questionable whether other ext2 implementations would recognise or honour such versioned files.
• It records block numbers in the classic Unix way, either directly in the inode or in single-/double-/triple-indirected blocks. While this is doubtless a very fast way of storing a file's block numbers, it requires the use of one entry per block. For a large, unfragmented file, this is far less space efficient than a list of extents.

There's no reason why ext2 couldn't store a Möbius file system without losing information, although modifying it to fit the requirements would be too much of a compromise to make it the native format.

NTFS: NTFS is Windows NT's native file system (and is also used by its successors, Windows 2000 and Windows XP). NTFS is a far heavier file system than ext2 and the NT implementation values reliability over speed. NTFS supports virtually all of the above requirements as-is (although adding versioning to the file system could be tricky). However, due to NTFS's complexity, the only known implementation that can reliably write to NTFS volumes is Microsoft's (one Linux driver is said to be able to write but can not do so reliably). Therefore NTFS is practically unsuitable as a native file system for Möbius.

BeFS: The Be File System was developed of Release 3 of the BeOS. It was designed as a good file system for a multimedia desktop OS. Like NTFS, it supports almost all of the requirements above, with the exception of versioning and compression. The implementation in the BeOS has been proven to be very fast (approaching the performance of ext2, even with the BeOS's less capable cache) and journalling makes it reliable. However, an implementation which used the BeFS would need to implement all its features (including journalling, and possibly queries) in order to be compatible. Although the BeFS driver source code was never made available, and with the demise of Be the number of other installations using the BeFS will decline (thus reducing its interoperatbility), the OpenBeOS project have apparently written a working BeFS implementation.

4.Conclusion

The Möbius cannot be a 'real' operating system without a capable file system behind it. Although it would be preferable to choose an already existing file system for native Möbius installations (the world already has enough incompatible file system formats), what is more important is that the chosen file system can achieve the requirements without compromise. ext2, although simple, cannot achieve most of the requirements without hacks. NTFS, although very capable, is too complex for use as an everyday file system outside of NT. BeFS is probably destined to go the same way as its parent operating system: it can only be saved by Open Source projects such as OpenBeOS.

5.References

• eks' file system links: http://onee.yi.org/#filesystems
• Ext2 Documentation Project: http://www.freesoftware.fsf.org/ext2-doc/
• Linux NTFS Project: http://linux-ntfs.sourceforge.net/
• OpenBeOS Project - BFS: http://open-beos.sourceforge.net/tms/team.php?bfs
• Dominic Giampaolo, Practical file system design with the Be file system (Morgan Kaufmann, 1998)