haiku/docs/develop/file_systems/overview.rst
Adrien Destugues 6b1db710f7 docs/develop: introduce intermediate index for each section
The table of content of the top level will include everything that's up
to 2 levels down. Currently this results in a lot of pages and no clear
organization.

Extra index pages allow for more intermediate levels, resulting in less
things being listed in the main page. This way the organization is a bit
clearer, even if this is still not great due to many missing pages and
sections in the documentation currently.

Change-Id: I5bbdd96b3c2ff3334b9ad1b86fd9e7fb00fd63a6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6008
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
2023-01-19 22:09:22 +00:00

84 lines
3.4 KiB
ReStructuredText

File systems overview
---------------------
Each filesystem driver must define a few structures which act as the
interface between the VFS and the filesystem implementation. These
structures contain function pointers, some of which are optional,
which should point to functions defined by the implementer that
perform the appropriate filesystem peration as defined by the
documentation.
See docs/user/drivers/fs_interface.dox for more detailed documentation
of this interface.
It's important to note that while there may be some similarities in
the interface with that of other operations systems, one should not
make any assumptions about the desired behavior based soley on the
function prototypes defined in fs_interface.h.
The following is a list of notes calling out some potential mistakes.
# fs_vnode_ops.read_symlink
Defining this function means that the filesystem driver supports
symbolic links, and the function that f_vnode_ops.read_symlink points
to should read the contents of a symlink from the specified node.
This may seem similar to the posix function readlink(), but it is
slightly different. Unlike readlink(), which returns the number of
bytes copied into the output buffer, fs_vnode_ops.read_symlink is
expected to always return the length of the symlink contents, even if
the provided buffer is not large enough to contain the entire symlink
contents.
Development tools
-----------------
fs_shell
........
It is not convenient to test a filesystem by reloading its driver into a
running Haiku system (kernel debugging is often not as easy as userland).
Moreover, the filesystem interacts with other components of the system
(file cache, block cache, but also any application reading or writing files).
For the early development steps, it is much easier to run the filesystem code
in a more controlled environment. This can be achieved through the use of
a "filesystem shell": a simple application that runs the filesystem code, and
allows performing specific operations through a command line interface.
Example of fs_shell implementations are available under src/tests/add-ons/kernel/file_systems/
for the bfs and btrfs filesystems.
For example, to build the fs_shell for btrfs, use
jam -q "<build>btrfs_shell"
To run it, use
jam run objects/haiku_host/x86_gcc2/release/tests/add-ons/kernel/file_systems/btrfs/btrfs_shell/btrfs_shell [arguments]
You need to pass at least a file or device containing a filesystem image as an
argument. You need some tool to create one. It is possible to work using an
actual disk volume (but be careful, it's risky to use one with useful data in it),
a file, or a RAM disk, depending on what you are doing.
userlandfs
..........
As a second step, it's possible to use the filesystem as part of a runing
system, while still running it in userland. This allows use of Debugger,
memory protection, and in general any kind of userland debugging or tracing
tool. When the filesystem crashes, it does not bring down the whole system.
Userlandfs can run the filesystem code using the same interface as the kernel,
therefore, once everything is working with userlandfs, running the filesystem
as kernel code is usually quite easy (and provides a performance boost)
Torture and performance tests
.............................
Once the basic operations are working fine, it is a good idea to perform more
agressive testing. Examples of scripts doing this are available in
src/tests/add-ons/kernel/file_systems/ for the fat and ext2 filesystems.