1Filesystem drivers 2================== 3 4Filesystem drivers are in src/add-ons/kernel/file_system 5 6A filesystem usually relies on an underlying block device, but that's not 7required. For example, NFS is a network filesystem, so it doesn't need one. 8 9Implementation notes 10-------------------- 11 12Each filesystem driver must define a few structures which act as the 13interface between the VFS and the filesystem implementation. These 14structures contain function pointers, some of which are optional, 15which should point to functions defined by the implementer that 16perform the appropriate filesystem peration as defined by the 17documentation. 18 19See docs/user/drivers/fs_interface.dox for more detailed documentation 20of this interface. 21 22It's important to note that while there may be some similarities in 23the interface with that of other operations systems, one should not 24make any assumptions about the desired behavior based soley on the 25function prototypes defined in fs_interface.h. 26 27The following is a list of notes calling out some potential mistakes. 28 29# fs_vnode_ops.read_symlink 30 31Defining this function means that the filesystem driver supports 32symbolic links, and the function that f_vnode_ops.read_symlink points 33to should read the contents of a symlink from the specified node. 34 35This may seem similar to the posix function readlink(), but it is 36slightly different. Unlike readlink(), which returns the number of 37bytes copied into the output buffer, fs_vnode_ops.read_symlink is 38expected to always return the length of the symlink contents, even if 39the provided buffer is not large enough to contain the entire symlink 40contents. 41 42Development tools 43----------------- 44 45fs_shell 46........ 47 48It is not convenient to test a filesystem by reloading its driver into a 49running Haiku system (kernel debugging is often not as easy as userland). 50Moreover, the filesystem interacts with other components of the system 51(file cache, block cache, but also any application reading or writing files). 52 53For the early development steps, it is much easier to run the filesystem code 54in a more controlled environment. This can be achieved through the use of 55a "filesystem shell": a simple application that runs the filesystem code, and 56allows performing specific operations through a command line interface. 57 58Example of fs_shell implementations are available under src/tests/add-ons/kernel/file_systems/ 59for the bfs and btrfs filesystems. 60 61For example, to build the fs_shell for btrfs, use 62 63 jam -q "<build>btrfs_shell" 64 65To run it, use 66 67 jam run objects/haiku_host/x86_gcc2/release/tests/add-ons/kernel/file_systems/btrfs/btrfs_shell/btrfs_shell [arguments] 68 69You need to pass at least a file or device containing a filesystem image as an 70argument. You need some tool to create one. It is possible to work using an 71actual disk volume (but be careful, it's risky to use one with useful data in it), 72a file, or a RAM disk, depending on what you are doing. 73 74userlandfs 75.......... 76 77As a second step, it's possible to use the filesystem as part of a runing 78system, while still running it in userland. This allows use of Debugger, 79memory protection, and in general any kind of userland debugging or tracing 80tool. When the filesystem crashes, it does not bring down the whole system. 81 82Userlandfs can run the filesystem code using the same interface as the kernel, 83therefore, once everything is working with userlandfs, running the filesystem 84as kernel code is usually quite easy (and provides a performance boost) 85 86Torture and performance tests 87............................. 88 89Once the basic operations are working fine, it is a good idea to perform more 90agressive testing. Examples of scripts doing this are available in 91src/tests/add-ons/kernel/file_systems/ for the fat and ext2 filesystems. 92 93.. toctree:: 94 95 /file_systems/userlandfs 96 /file_systems/ufs2 97 /file_systems/xfs 98 /file_systems/befs/resources 99