Project: Linux Howtos

Virtual file system Part 1

By Vans Information <content@vansinfo.com>
Posted: ( 2001-03-22 13:26:40 EST by )
When the Linux kernel has to access a File System, it uses a file-system-type independent interface, which allows the system to carry out operations on a File System without knowing its construction or type. Since the kernel is independent of File System type or construction, it is flexible enough to accommodate future File Systems as and when they become available.

Virtual File System is an interface providing a clearly defined link between the operating system kernel and the different File Systems. The VFS supplies the applications with the system calls for file management (like “open”, “read”, “write” etc.), maintains internal data structures (the administrative data for maintaining the integrity of the File System), and passes tasks onto the appropriate actual File System. Another important job of the VFS is, performing standard actions. For example, as a rule, no File System implementation will actually provide an lseek() function, as the functions of lseek() are provided by a standard action of the VFS.

Kernel’s representation of the File Systems
The representation or layout of data on a floppy disk, hard disk or any other storage media may differ considerably from one implementation of File System to another. But the actual representation of this data in Linux kernel’s memory is the same for all File System implementations. The Linux management structures for the File Systems are similar to the logical structure of a Unix File System.

The VFS calls the file-system-specific functions for various implementations to fill up these structures. These functions are provided by every File System implementation and are made known to the VFS via the function register_filesystem(). This function sets up the file_system_type structure it has passed, in a singly linked list headed by the pointer “file_systems”. The file_system_type structure gives information about a specific File System implementation. The structure is as follows:

struct file_system_type
{
struct super_block *(*read_super)(struct super_block *, void *, int);
char *name;
int requires_dev;
struct file_system_type *next;
};

· The function “read_super(..)” forms the mount interface, i.e. it is only via this function that further functions of the File System implementation will be made known to the VFS. It takes three parameters:

* A super_block structure in which the data relevant to this instance of File System implementation is filled up.

* A character string (in this case void *), which contains further mount options for the file system.

* A flag, which is used to indicate whether unsuccessful mounting should be reported. This flag is used only by the kernel function mount_root(), as this calls all the read_super() functions present in the various File System implementations.

* The “name” field contains the name of the actual File System.

* “requires_dev” is a flag indicating whether a device is strictly necessary to mount the File System from.

A typical statement to register a File System would look similar to the following code:

#ifdef CONFIG_EXT2_FS
register_filesystem(&(struct file_system_type) {ext2_read_super, “Ext2”, 1, NULL});
#endif

Once a File System implementation has been registered with the VFS, file systems of this type can be administered.

Mounting a file system

In order to access a file, the file system containing the file must be mounted onto some mount point in the Linux directory hierarchy. This can be done using either the mount system call or the mount_root() function.

After all the File System implementations permanently included in the kernel have been registered, the setup() system call (which is called immediately after the init process is created by the kernel function init()) makes a call to the mount_root() function which takes care of mounting the first File System (the root File System).

A separate superblock structure is maintained for every mounted File System. These structures are held in the static table super_block[], which has the capacity for holding NR_SUPER such entries. The superblock is initialized by the function read_super() in the VFS. This file-system-specific function reads its data if necessary from the appropriate block device using the LINUX cache functions.

The Linux superblock has the following structure:

Struct super_block
{
dev_t s_dev; /* device for File System */
unsigned long s_blocksize; /* block size */
unsigned char s_blocksize_bits; /* ld (block size) */
unsigned char s_lock; /* superblock lock */
unsigned char s_rd_only; /* not used (= 0) */
unsigned char s_dirt; /* superblock modified */
struct file_system_type *s_type; /* file system type */
struct super_operations *s_op; /* super block operations */
unsigned long s_flags; /* flags */
unsigned long s_magic; /* file system identifier */
unsigned long s_time; /* time of change */
struct inode * s_covered; /* mount point */
struct inode * s_mounted; /* root inode */
struct wait_queue * s_wait; /* s_lock wait queue */
union
{
struct minix_sb_info minix_sb;
……….
void * generic_sdp;
} u; /* file-system-specific information */
};

The superblock contains information on the entire File System, such as block size, access rights and time of the last modification. In addition, the union u at the end of the structure holds special information on the relevant file system. For file system modules mounted later, there is a pointer generic_sdp. The components s_lock and s_wait are used to ensure synchronized access to the superblock. The superblock also holds reference to the file system’s root inode “s_mounted” and the inode of the mount_point “s_covered”.

Superblock Operations

The superblock provides pointers to functions, for accessing the file system, in the function vector s_op. These functions are used to perform all the operations on the File System. The super_operations structure is as follows:

struct super_operations
{
void (*read_inode) (struct inode *);
int (*notify_change) (struct inode *, struct iattr *);
void (*write_inode) (struct inode *);
void (*put_inode) (struct inode *);
void (*put_super) (struct super_block *);
void (*write_super) (struct super_block *);
void (*statfs) (struct super_block *, struct statfs *);
int (*remount_fs) (struct super_block *, int *, char *);
};

The functions in the super_operations structure serve to read and write an individual inode, to write the superblock and to read filesystem information. This means that the superblock operations contain functions to transfer the specific representation of the superblock and inode on the data media to their general form in memory and vice versa. As a result, this layer completely hides actual representations. The operations listed in the structure are as follows:

* write_super(sb)
This function is used to save the information of superblock back on to the storage media. However, this doesn’t guarantee the consistency of the file system due to the caching of inode and data blocks done by LINUX. It is used for synchronizing the device and is ignored by the read-only file systems.

* put_super(sb)
The VFS calls this function when unmounting file systems, when it should also release the superblock and other information buffers.

* statfs(sb, statfsbuf)
The system calls statfs and fstatfs call this superblock operation, which fills in the statfs structure that provides information on the file system, like the number of free blocks and the preferred block size.

* remount_fs(sb, flags, options)
This involves entering the new attributes for the file system in the superblock and restoring the consistency of the file system.

* read_inode(inode)
This function fills up the inode structure passed to it. It is called by the function __iget(). It distinguishes between the different file types by entering inode operations in the inode according to the file type.

* notify_change(inode, attr)
Used to acknowledge the changes made to the inode passed. In most of the File System implementations, it is not provided.

* write_inode(inode)
This function saves the contents of the inode passed as parameter onto the storage media.

* put_inode(inode)
This function is called by i_put() if the inode is no longer required. Its purpose is to delete the file permanently and release its blocks if there are no links to the file.

Other articles by Vans Information

Current Rating: [ 5.67 / 10 ] Number of Times Rated: [ 46 ]

Contents Articles   Howtos   Interviews   News   Opinions   Reviews Comparison Links   Articles   Howtos   Interviews   Opinions   Reviews   Websites News

Linux About Linux

Print It! Printer Friendly Version