Evolving a privilege system on top of the DCOS.

Currently DCOS does scheduling based on resources available. Job of an OS is more . It itself runs with
the highest privileges and doesn’t

Today we discuss about some of the kernel features which we can do in userspace. One of such things is
writing a file system in userspace. The feature is called FUSE (File System in user space). The question to
be asked is as to why we ought to even do this. The rationale of implementing a Filesystem in userspace
apart from giving you more control over the file operations , it also allows you to achieve more
portability without implementing a kernel module and can easily be ported even via containerization
mechanisms. Also a bug wont bring the kernel down as this is completely a userspace implementation.

So in this blog we cover the basics of what is FUSE and design of it. In forthcoming blogs, we try to
implement a Filesystem in userspace ourselves.

We can at a high level break the semantics of FUSE into 3 parts

1. A kernel module called FUSE (fuse.ko)

2. A userspace library called libfuse
3. Mount utility called fusermount

The filesystem type can be of types

1. Fuse
2. Fuseblk
Image courtesy Wikipedia

So basically the flow is like this

1. Application in userspace makes a system call say via glibc to the VFS for a file operation
2. If filesystem type is fuse, the VFS invokes the Fuse kernel module
3. Fuse in turn invokes back the userspace library libfuse via glibc . This is where the operations get
invoked on the filesystem in userspace
4. Libfuse is the interface to the userspace Filesystem which is instrumental in then making the
actual filesystem calls.

Technically anything can be represented as a filesystem operation. As an example git operations can be
modelled as file operations via Fuse based file system called gitfs. Another example would be to model
an objectstorage like S3 via S3fs. Email systems like gmail can be exposed gmailfs. Some other examples
are glusterfs for a distributed filesystem and encfs which allows filesystem encryption.

There is another interesting example of userspace filesystem called errfs (being used by frameworks like
CORDS), for injecting faults in the filesystem for testing resiliency of softwares sitting on top of those
filesystems.

Some of the core functions which need to be implemented as part of the FUSE filesystem include

1. getattr(self, path)
2. readdir(self, path, offset)
3. mknod(self, path, mode, dev)
4. unlink(self, path)
5. read(self, path, size, offset)
6. write(self, path, buf, offset)
7. release(self, path, flags)
8. open(self, path, flags)
9. truncate(self, path, size)
10. utime(self, path, times)
11. mkdir(self, path, mode)
12. rmdir(self, path)
13. rename(self, pathfrom, pathto)
14. fsync(self, path, isfsyncfile

in next blog we go over the details on how to implement such a filesystem

As covered in previous blog on the basics of FUSE. We in this blog take a simple example to write a FUSE
based filesystem.

In the example we write a hello world FUSE file system which exposes the following operations

1. hello_readaddr - returns the exact structure of the directory read.

2. hello_open - We just have a memory resident file and nothing to be read from disk, we just
return 0
3. hello_getattr - This is the callback made whenever the call to read the meta-data about a file(dir
or file is made) . In our example if we encounter / then we declare it as a dir and return. If we
read the file (file in our example), we return the filesize
4. hello_read – We return the content of the file opened
The fuse operations is where all callback functions are defined.

Launching the program does the mount of the fuse file system on /tmp/example

Doing a ls in the directory /tmp/example

And the logs on mounted filesystem side show

Reading the file via cat hello

And filesystem logs show

We can see the operation read being called and the file exposed via the filesystem is read.