1 UNIX Internals – The New Frontiers Chapters 8 & 9 File Systems

2 Contents u The User Interface to Files u File System u File System Framework u The Vnode/VFS Architecture u Implementation Overview u File-System-Dependent Objects u Mounting a File System u Operations on Files u The System V File System(s5fs) u S5fs Kernel

3 8.2 The User Interface u files, directory, file descriptor, file systems u File & Directories u File: logically a container for data u A hierarchical, tree-structured name space u Pathname: all the components in the path from the root to the node, by “/” u “.” & “..” u Link: a directory entry for a file.

4 Directory tree

5 Operation on directory u dirp = opendir(const *filename); u direntp = readdir (dirp); u rewinddir(dirp); u status = closedir(firp); u struct dirent { int_t d_ino; char d_name[NAME_MAX +1]; };

6 File Attributes u Kept in the inode: index node u File attributes: u File type u Number of hard links u File size u Device ID u Inode number u User and Group Ids of the owner of the file. u Timestamps u Permissions and mode flags

7 Permissions and mode flags u 0wner, group, others (3 x 3 bits) u Read, write, execute (3 bits) u Mode flags - apply to executable files - suid, sgid – to set the user’s effective UID to that of the owner of the file, - stick – to retain file in swap area

8 System calls u link, unlink – to create and delete hard links u utimes – to change the access and modify timestamps, u chown – to change the owner UID and GID, u Chmode – to change permissions and mode flags.

9 File Descriptors u fd = open (path, oflag, mode); u fd is a per-process object.

10 File descriptors

11 File I/O u Random and sequential access u lseek – random access u nread = read(fd, buf, count); u Write has similar semantics u Operations are serialized u In append mode offset pointer set to the end of the file

12 Scatter-Gather I/O u nbytes = writev(fd, iov, iovcnt);

13 File Locking u Read and write are atomic. u Advisory locks: protect from cooperative processes, flock() in 4BSD; in SVR3 chmod must be enabled first u SVR4: r/w locks. u Mandatory locks:kernel u C library function lockf

File systems u Mount-on - a directory is covered by the mounted file system. - mount table (original) & vfs list (modern) u Restrictions - file cannot span file system, - each file system must reside on a single logical disk

15

16 Logical Disks u A logical disk is a storage abstraction that the kernel sees as a linear sequence of fixed sized, randomly accessible blocks. u newfs, mkfs, u Traditional: partition – physical storage of a file system u Modern configurations: u Volume (several disks combined), u Disk mirroring u Stripe sets u RAID(Redundant Array of Inexpensive Disks)

17 Special files u Generalization to include all kinds of I/O related objects such as directories, symbolic links, hardware devices (disks, terminals, printers, psuedodevices such as the system memory, and communications abstractions such as pipes and sockets; u Problems with hard links – may not span file systems,can be created by superuser only, ownership problems,

18 Special files u Symbolic links – special file that points to another file (linked-to file); the data portion of the file contains the pathname of the linked-to file; may be stored in the I-node of the symbolic link ( more on this in Practical UNIX Programming pp.90-96); u Pipes – created by pipe system call, deleted by the kernel automatically u FIFOs - created by mknod system call, must be explicitly deleted;

File System Framework u Traditional UNIX can not support >1 types of FS. u The new developments (DOS, file sharing, RFS, NFS) require the framework to change. u AT&T: file system switch u Sun Microsystem: vnode/vfs u DEC: gnode u SVR4:(AT&T+ vnode/vfs+NFS)-> de facto standard

The Vnode/Vfs Architecture u Objectives u Support several file system types simultaneously. u Different disk partitions may contain different types of file systems. u Support for sharing files over a network. u Vendors should be able to create their own file system types and add them to the kernel.

21 Lessons from Device I/O u Devices: block & character u Character device switch: struc cdevsw { int (*d_open)(); int (*d_close)(); int (*d_read)(); int (*d_write)(); } cdevsw[ ]; u Major device number: as the index

22 read system call(in traditional UNIX) 1) Use the file descriptor to get to the open file object; 2) Check the entry to see if the file is open for read; 3) Get the pointer to the in-core inode from this entry; 4) Lock the inode so as to serialize access to the file; 5) Check the inode mode field and find that the file is a character device file. 6) Use the major device number to index into a table of character devices and obtain the cdevsw entry for this device; 7) From the cdevsw, obtain the pointer to the d_read routine for this device; 8) Invoke the d_read operation to perform the device- specific processing of the read request. 9) Unlock the inode and return to the user.

23 Lessons from Device I/O u It is necessary to separate the file subsystem code into file-system- independent code and file-system- dependent code u The interface between these two parts is defined by a set of generic functions that are called by the file system- independent code

24 Object Oriented Design

25 Overview of the Vnode/Vfs Interface u Vnode represents a file in the UNIX kernel. u Vfs represents a file system

26 )

27 base class data and operations pointers u v_data: inode(s5fs), rnode(NFS), tmpnode(tmpfs), u v_op: vnodeops Example: to close the file associated with the vnode u #define VOP_CLOSE(vp,…) (*((vp)->v_opclose))(vp,…)

28 VFS base class

Implementation Overview u Objectives u Each operation must be carried out on behalf of the current process. u Certain operations may need to serialize access to the file. u The interface must be stateless and reentrant. u FS implementation should be allowed to use global resources, such as buffer cache. u The interface should be usable by the server side u The use of fixed-size static tables must be avoided.

30 Vnodes and Open Files u The vnode is the fundamental abstraction that represents an active file in the kernel. u access to a vnode: u by a file descriptor u by file-system-dependent data structures

31 Data structures Reference count

32 The Vnode struct vnode {u_short v_flag; u_short v_count; struct vfs *vfsmountedhere; struct vnodeops *v_op; struct vfs *vfsp; … }; // p242

33 Vnode Reference Count u It determines how long the vnode must remain in the kernel. u Reference versus lock: u Acquire a reference: u Open a file u A process holds a reference to its current directory. u When a new file system is mounted u Pathname traversal routine u file is deleted physically when reference count becomes zero.

34 The Vfs Object u struct vfs { u struct vfs *vfs_next; u struct vfsops * vfs_op; u struct vnode *vfs_vnodecovered; u int vfs_fstype; u caddr_t vfs_data; u dev_t vfs_dev; u … u }; //p243

35

File-System-Dependent Objects u The Per-File Private Data u Vnode is an abstract objects.

37 The vnodeops Vector struct vnodeops{ int (*vop_open)(); int (*vop_close)(); … }; //p245 For ufs: struct vnodeops ufs_vnodeops = { ufs_open; ufs_close; … }; //p246

38

39 File-System-Dependent Parts of the Vfs Layer struct vfsops { int (*vfs_mount)(); int (*vfs_unmount)(); int (*vfs_root)(); int (*vfs_statvfs)(); int (*vfs_sync)(); … }; //p246

40

Mounting a File System u mount(spec, dir, flags, type, dataptr, datalen) //SVR4 u Virtual File System Switch - a global table containing one entry for each file system type. struct vfssw{ char *vsw_name; int (*vsw_init)(); struct vfsops * vsw_vfsops; …. } vsfsw[];

42 mount Implementation u Adds the structure to the linked list headed by rootvfs. u Sets the vfs_op field to the vfsops vector specified in the switch entry. u Sets the vfs_vnodecovered field to point to the vnode of the mount point directory.

43 VFS_MOUNT processing u Verify permissions for the operation. u Allocate and initialize the private data object of the file system. u Store a pointer to it in the vfs_data field of the vfs object. u Access the root directory of the file system and initialize its vnode in memory.

Operations on Files Pathname Traversal lookuppn(): u_cdir 1. v_type is of a directory 2. “..” & system root – move on 3. “..” & a mounted system root – access the mount point 4. VOP_LOOKUP 5. Not found, last one - success, else – error ENOENT 6. A mount point - go to the mounted vfs root 7. A symbolic link – translate it and append 8. Release the directory 9. Go back to the top of the loop 10. Terminate, do not release the reference of the final vnode //p250

45 Opening a file fd = open(pathname, mode) 1. Allocate a descriptor 2. Allocate an open file object 3. Call lookuppn() 4. Check the vnode for permissions 5. Check for the operations 6. Not exist, O_Creat, VOP_CREAT; ENOENT 7. VOP_OPEN 8. If O_TRUNC, VOP_SETATTR 9. Initialize 10. Return the index of the file descriptor //p252

46 Other topics u File I/O u File attributes u User credentials u Analysis u Drawbacks of the SVR4 Implementation u The 4.4 BSD Model

47 Chapter 9 File System Implementations

The System V File System(s5fs) u The layout of s5fs partition: u Directories: u s5fs directory is a special file containing a list of files and subdirectories. B S inode list data blocks

49 Inodes u The inode contains administrative information,or meta data. u The node list contains all the inodes. u On-disk inode - see Tab. 9-1 u In-core inode have more fields

50 Inode Fields

51 di_mode Bit-fields

52 Block array of inode—di_addr inode 10, 10K 256, 256K 256*256=65K, 65M 256*256*256=16M, 16G

53 The superblock u Size in blocks of the file system u Size in blocks of the inode list u Number of free blocks and inodes u Free block list u Free inode list

54 Free block list

s5fs Kernel Organization u In-core Inodes u The vnode u Device ID u Inode number of the file u Flags for synchronization and cache management u Pointers to keep the inode on a free list u Pointers to keep the inode on a hash queue. u Block number of last block read

56 Allocating and Reclaiming Inodes u Inode table(LRU) containing the active inodes u Reference count of a vnode ==0 the reclaim the inode as free u Iget()(allocating):

57 Inode lookup u s5lookup() u Checks the directory name lookup cache u Directory name lookup cache Miss? Reads the directory one block at a time, searching the entries for the specified file name:Get it u If the file is in the directory, get the inode number, use iget() to locate the inode, u Inode in the table?get it: allocate a new inode, initialize, copy, put in the hash queue, also initialize the vnode(v_ops, v_data, vfs) u Return the pointer to the inode

58 File I/O (1) u Read(to a user buffer address) u Fd-> the open file object, verify mode-> vnode-> get the rw-lock->call s5read() u Offset -> block number & the offset -> uiomove()-> call copyout() u The page not in memory?page fault->the handler- >s5getpage()->call bmap() u logical to physical mapping, search vnode’s page list, not in?allocates a free page and call the disk driver to read the data from disk u Sleeps until the I/O completes. Before copying to user data space, verifies the user has access u s5read() returns, unlock, advances the offset, returns the number of bytes read

59 File I/O (2) u Write: u Not immediately to disk u May increase the file size u May require the allocation of data blocks u Read the entire block, write relevant data, write back all the block

60 Allocating and reclaiming Inodes u When the reference count drops to 0.. u When a file becomes inactive…. u It is better to reuse inodes…………

61 Analysis of s5fs u Reliability concern : super block u Performance: u 2 disk I/Os u Blocks randomly located u Block size: 512(SVR2), 1024(SVR3) u Name: 14 characters u Inodes limit: 65535

62 The Berkeley Fast File System u Hard disk structure u On-disk organization - Blocks and fragments - Allocation policy u FFS functionality enhancements – long file names, - symbolic links, - other enhancements; u Analysis

63 Other file systems u Temporary file systems - RAM disk, mfs, tmpfs) u The Specfs File System u The /proc File System

64 Linux Virtual File System u Uniform file system interface to user processes u Represents any conceivable file system’s general feature and behavior u Assumes files are objects that share basic properties regardless of the target file system

65

66

67 Primary Objects in VFS u Superblock object u Represents a specific mounted file system u Inode object u Represents a specific file u Dentry object u Represents a specific directory entry u File object u Represents an open file associated with a process