NILFS

[email protected] 1 Introduction To enhance reliability of the Linux file system, we adopted a Log Structured File System (LFS)[1]. In the past, the advantages of LFS were high write perfor- mance and faster recovery time. In addition, LFS pre- vents data write operations from overwriting the disk blocks, thereby minimizing damage to the file data and file system consistency and avoiding a hardware failure. Furthermore, LFS writes data and meta-data in the cor- rect order, which helps ensure file system consistency. The position of the writing blocks are evenly distributed around the disk, thus reducing the possibility of a disk hardware failure. LFS can create a snapshot of the file system immediately and makes the system user friendly. Presently, we are developing the Nilfs (the New Im- plementation of a Log-structured File System) as a ker- nel module in Linux 2.6. 2 the Goal of the Nilfs The goals of the Nilfs are as follows. 1. Respect Linux semantics 2. Avoiding modifications to the kernel code This simplifies Nilfs installation and following up a frequent version rise of the Linux kernel speedy. 3. Getting high reliability, availability and operability For example, the file systems are reliable, like DBMS, and immediately takes its snapshot. 4. High performance and scalability 5. Adapting the distributed file system or the cluster system 6. Being user friendly It reduces the possibility of human errors. We also included our future work in this development goal. From these, we set guaranteed high reliability and availability as our main goals. 3 the Log Structured File System The LFS writes all modifications to the disk sequentially, no blocks are overwritten, and log-like structures are ap- pended to the disk instead. Meta-data, such as file in- odes and indirect blocks are written to newly allocated blocks. In LFS, data writing does not break any exist- ing disk blocks on system failure such as power down. A new disk block address is assigned to the data on the memory buffer cache during write operations. The as- signments are in the following order; file data, file data indirect blocks, inode blocks, and inode indirect blocks. This order is important for maintaining the consistency of the file system structure. Write operations are also performed in this order, without having to seek the disk head. The write position is contiguous and stable, and the file system check (fsck) process only inspects a small area of the disk. Because disk capacity is limited, we need a “garbage collection” service (or cleaner) to collect deleted file blocks and logically overwritten blocks. Garbage collec- tion is a major overhead of LFS. However, the garbage collector can efficiently restore fragmented file blocks. For efficient garbage collection, whole disk is divided into fixed sizes (ex. 4 mega bytes). This management unit is called a full segment. Writing out is done sequen- tially in full segments. 4 Nilfs Disk Layout In Nilfs, our design goals are to obtain high reliability and availability of the file system. We have not yet begun performance tuning. However, to be able to use the Nilfs in the future, the file size and inode numbers are stored in 64-bit-wide fields, and file blocks are managed by a B- tree[2][3]. The root of the file block B-tree is placed on the inode structure. The inode is managed by the inode block B-tree, the root of the inode block B-tree is stored in the superblock structure of the file system. In this section, we will first show the layout of the whole disk, and then explain the management structure of file blocks. 4.1 Disk Layout The disk layout of Nilfs is shown in Figure 1, divided into several parts. superblockSuperblock has the parameters of the file system, the disk block address of the latest segment seg 0seg 1 ... seg n superblock segment management partial segment logical segment Figure 1: disk layout of the Nilfs being written, etc. The inode block B-tree root is stored on the latest segment, so i