File system API

A filesystem [[Application_programming_interface|API] is an application programming interface that allow developers to add support of a filesystem to an operating system without needing the second to know anything about what filesystem is it or how it works.

It is similar in functionality to driver APIs, as programs and the operating system itself know nothing about the filesystem.

Ocassionally they also provide interfaces so common filesystem maintenance functions (such as making a new filesystem, checking the metadata's integrity, defraging it and so on) became universal and transparent to the applications that handle them.

History

In the principle, the operating systems were capable of handling only a disk filesystem, but as systems expanded two problems arised: -- Network shares required to appear to the user as local disks. -- Users wanted to interchange files with other users, than can have another operating system.

With the old scheme, all filesystems and network protocols are specific to the operating system's kernel and when the user tried to access a file the whole kernel knowed how the filesystem or network protocol worked. With the two problems arised, this scheme meant that adding support for a filesystem will require a major kernel rewrite, and this wasn't acceptable, so operating systems designer think about separating the specific filesystem code from the file and network handling code of the kernels, and the filesystem APIs appeared.

Kernel-based API

The API is "kernel-based" when the kernel not only provides the interfaces for the filesystems developers but is also where the filesystem code reside.

It differs with the old schema in that the kernel itself uses its own facilities to talk with the filesystems and viceversa, as contrary to being the kernel the one that handles the filesystem layout and the filesystem the one that directly access the hardware.

Isn't the cleaner scheme but resolves the difficulties of major rewrite that has the old scheme.

With modular kernels it allows adding filesystems as any kernel module, even third party ones. With non-modular kernels however it requires the kernel to be recompiled with the new filesystem code (and in closed-source kernels, this makes third party filesystem impossible).

An example of this scheme is the UNIXes' and Linux's VFS.

There is a variation of this scheme that is used in MS-DOS and compatibles for making it support CD-ROM and network filesystems, that instead of adding code to the kernel as in the old scheme or using kernel facilities as in the kernel-based scheme, it traps all calls to a file and identifies if it should be redirected to the kernel's equivalent function or if it has to be handled by the specific filesystem driver, and the filesystem driver "directly" access the disk contents using the classic low-level BIOS functions.

Driver-based API

The API is "driver-based" when the kernel provides facilities but the filesystem code resides totally external to the kernel (not even as a module of a modular kernel).

It is the cleaner scheme as the filesystem code is totally independent, it allows filesystems to be created for closed-source kernels and on-line filesystem addition or extraction to/from the system.

Examples of this scheme are the Windows NT and OS/2 respective IFSs.

Userland-based API

The API is "userland" when the filesystem doesn't use kernel facilities (if they are available) but access disks using high-level operating system functions and provides functions in a library that a series of utilities uses to access the filesystem.

This is very useful for handling disk images.

The great advantage is that the filesystem can be easily portable between operating system as the high-level functions it will be using can be as common as ANSI C, but the great disadvantage is that the API is uniquely to each application that implements one.

Examples of this scheme are the [[1]] and the [[2]].

Interoperatibility between filesystem APIs

As all filesystems (at least the disk ones) should need equivalent functions provided by the kernel, it is possible to easily port a filesystem code from one API to another, even if they are of different types.

For example, the ext2 driver for OS/2 is simply a wrapper from the Linux's VFS to the OS/2's IFS and the Linux's ext2 kernel-based, and the HFS driver for OS/2 is a port of the hfsutils to the OS/2's IFS. And there exists also a project that uses a Windows NT IFS driver for making NTFS work under Linux.