Linux retains UNIX's standard file-system model. UNIX files can be anything capable of handling the input or output of a stream of data. Eg: Device drivers, interprocess communication channels or network connections also look like files to the user.
The Linux kernel handles all these types of files by hiding the implementation details of any single file type behind a layer of software, the virtual file system. (VFS).
1)Virtual file system
2)Standard Linux file system- ext2fs.
REAL TIME FACTS
• Unix uses a hierarchical file system structure, with root (/) at the base of the file system and all other directories spreading from there.
• A filesystem is a collection of files and directories that has the following properties -
•It has a root directory (/) that contains other files and directories.
•Each file or directory is uniquely identified by its name, the directory in which it resides, and a unique identifier, typically called an inode.
• Some directories that exist on the major versions of Unix :
/ Root directory which should contain only the directories needed at the top level of the file structure
/bin This is where the executable files are located.
/dev These are device drivers
/etc Supervisor directory commands, configuration files
/lib Shared library files and sometimes other kernel-related files
/boot Contains files for booting the system
/home Contains the home directory for users and other accounts
/mnt Used to mount other temporary file systems
i)The Virtual File System
The Linux VFS is designed around object-oriented principles and has two components:
A layer of software to manipulate the objects.
The VFS defines four main object types:
• An inode object represents an individual file.
• A file object represents an open file.
• A superblock object represents an entire file system.
• A dentry object represents an individual directory entry.
• Every object of these types contains a pointer to a function table which lists the addresses of the actual functions that implement the defined operations for that object.
• Some of the file object's operations includes:
int open ( . . .) - Open a file. ssize_t read(...) -Read from a file. ssize_t write (. . .) - Write to a file. int mmap (...) - Memory-map a file.
• The complete definition of the file object is specified in the struct file_operations, which is located in the file /usr/include/linux/fs.h.
• The VFS software layer can perform an operation on one of the file-system objects by calling the appropriate function from the object's function table, without having to know in advance exactly what kind of object it is dealing with.
The inode object
The inode and file objects are the mechanisms used to access files.
An inode object is a data structure containing pointers to the disk blocks that contain the actual file contents.
The UNIX programming interface defines a number of operations on directories, such as creating, deleting, and renaming a file in a directory.
The system calls for these directory operations do not require that the user open the files concerned.
The VFS therefore defines these directory operations in the inode object, rather than in the file object.
File object and Superblock Object
• A file object represents a point of access to the data in an open file and keeps track of where in the file the process is currently reading or writing, to keep track of sequential file I/O.
• A process cannot access an inode's contents without first obtaining a file object pointing to the inode.
• The superblock object represents a connected set of files that form a self- contained file system.
• The operating-system kernel maintains a single superblock object for each disk device mounted as a file system and for each networked file system currently connected.
•The main responsibility of the superblock object is to provide access to inodes.
- The VFS identifies every inode by a unique file-system/inode number pair, and it finds the inode corresponding to a particular inode number by asking the superblock object to return the inode with that number.
- A dentry object represents a directory entry that may include : The name of a directory in the file's pathname (such as /usr) Or the actual file (such as stdio. h).
For example, the file /usr /include/ stdio. h contains the directory entries (1) /, (2) usr, (3) include, and (4) stdio. h.
Each one of these values is represented by a separate dentry object.
The Linux ext2fs File System
• Linux was originally programmed with a Minix-compatible file system, to ease exchanging data with the Minix development system.
• The Minix file system was superseded by a new file system, the extended file system (extfs).
• A later redesign of this file system to improve performance and scalability and to add a few missing features led to the second extended file system (ext2fs).
• In ext2fs,Directory files are stored on disk just like normal files, although their contents are interpreted differently.
• Each block in a directory file consists of a linked list of entries; each entry contains the length of the entry, the name of a file, and the inode number of the inode to which that entry refers.
To know the file system present in your system use df command..
The ext2fs allocation policy
- The ext2fs allocation policy comes in two parts.
- An ext2fs file system is partitioned into multiple block groups.
- Each group corresponds to a single cylinder of a physical disk, and involves allocation for files, inode, directories.
- When allocating a file, ext2fs must first select the block group for that file. For data blocks, it attempts to allocate the file to the block group to which the file's inode has been allocated.
- For inode allocations, it selects the block group in which the file's parent directory resides, for nondirectory files.
- Directory files are not kept together but rather are dispersed throughout the available block groups.
- One popular feature in a file system is journaling, whereby modifications to the file system are sequentially written to a journal.
- A set of operations that performs a specific task is a transaction. Once a transaction is written to the journal, it is considered to be committed, and the system call modifying the file system (write()) can return to the user process, allowing it to continue execution.
As the changes are made, a pointer is updated to indicate which actions have completed and which are still incomplete. When an entire committed transaction is completed, it is removed from the journal.
The journal, which is actually a circular buffer, may be in a separate section of the file system, or it may even be on a separate disk spindle.
- If the system crashes, some transactions may remain in the journal.
- Those transactions were never completed to the file system even though they were committed by the operating system, so they must be completed once the system recovers.
- The transactions can be executed from the pointer until the work is complete, and the file-system structures remain consistent.