Pseudo Filesystems

Filesystems do not necessarily require an underlying block medium. They can either use memory as backing store, as is the case for ramfs and tmpfs, or can require no backing store at all, as procfs and sysfs do — their contents are generated synthetically from information contained in the kernel's data structures. While filesystems of this type are already quite distinct from the traditional concepts, it is still possible to take a further step forward. How? All filesystems, be they virtual or not, have one common property: They are visible to userspace in the form of files and directories. However, this property is not sacrosanct. Pseudo-filesystems are filesystems that cannot be mounted and are thus never directly visible in userland.

This does not seem overly useful at a first glance. What is a filesystem good for if it does not export anything to userland? While files and directories are, indeed, one possible and without doubt useful representation of the contents of a filesystem, they are not the only one. It is also perfectly valid to think of a filesystem solely in terms of inodes! Files and directories are only a front end in this picture, and they can be omitted without any loss of information.

Except visibility to userland. But this does not really concern the kernel. On some occasions, the need can arise to internally group inodes together, and userland need not know anything about this. The kernel, however, can benefit from organizing such collections in the form of filesystems because all standard auxiliary functions that work for regular filesystems will automatically work for such collections as well.

Particular examples of pseudo-filesystems are bdev to manage inodes that represent block devices, pipefs to handle pipes, and sockfs to deal with sockets. All appear in /proc/filesystems, but cannot be mounted:

[email protected] # cat /proc/filesystems nodev bdev nodev sockfs nodev pipefs [email protected] # mount -t bdev bdev /mnt/bdev mount: wrong fs type, bad option, bad superblock on bdev, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so

The kernel provides the mount flag ms_nouser to prevent a filesystem from being mounted. Apart from this, all filesystem mechanisms work as discussed in this chapter. The kernel can mount a pseudo-filesystem with kern_mount or kern_mount_data. This ends up in vfs_kern_mount, which integrates the filesystem data into the VFS data structures.

When a filesystem is mounted from userland, do_kern_mount is not sufficient. Integration of the files and directories into the user-visible representation is afterward handled by graft_tree. The method, however, refuses to perform its job if the flag ms_nouser is set:

Continue reading here: File Operations

Was this article helpful?

0 0