From the kernels point of view

Before we can start designing the architecture of a metadata file system, we will need to know what the kernel is expecting of the file system. As we already know the kernel can be considered as a layer between the applications (user space) and the actually hardware. In user space the programmer can make use of system call (calling a method in the kernel), which the kernel will have to answer in a well defined way. For instance let's say we would like to write a C program which open a file, then we could write something like this:

#include <stdio.h>

int main(){
  fopen("testfile", "R");
  return 0;
}

The file should be compiled:

$gcc -o openfile -O0 -static openfile.c

At this point we have a very simple binary, which open a file named testfile. We can execute the program using strace which will print every system call which are preformed to stderr, and in this way enable us to see what happens, this is done in the following snippets:

$ strace ./openfile
execve(``./openfile'', [``./openfile''], [/* 60 vars */]) = 0
uname({sys=``Linux'', node=``majs'', \ldot.})  = 0
brk(0)                                  = 0x80be000
brk(0x80becb0)                          = 0x80becb0
set_thread_area({entry_number:-1 -> 6, base_addr:0x80be830,... 
brk(0x80dfcb0)                          = 0x80dfcb0
brk(0x80e0000)                          = 0x80e0000
open(``testfile'', O_RDONLY)            = 3
exit_group(0)                           = ?

The only system call of interest is open(``testfile'', O_RDONLY), which kindly as the kernel to open the given file. It seems quite simple, at least from the user space point of view, but opening a file is not simple at all. To be able to open a given file we must know which block device the file is stored on, the Linux kernel supports a large set of different block devices which all need a specific drive which know how to communicate which this particular block device. When we have lined up the correct block device, and the correct driver, we will need to figurer out which file system are installed on the block device. As with block devices the Linux kernel also supports a large set of different file systems (ext2, vfat, reiserfs, xfs just to mention a few), each of these file systems uses different data structures, some is based on inodes, some is not. At this point we will need to look up the inode for the given file¹⁰ and thereby check if it exits. And finally we can return a file descriptor. This short description was simplified a lot, just to give you an basic overview on what happens when the kernel is asked to open a file. In the next chapter well dick into more details on how the kernel handles different file systems. A block diagram of the subsystems which have been discussed can be found at figure 1.

Figure 1: A simplified block of the kernel modules which are used when a file us opened, read and/or written