CSCC69: Operating Systems Assignment 3 Review

Assignment Review Implement the file-related system calls – open, close, dup2 – read, write, lseek – chdir, getcwd – Fstat, getdirentry Implement getdirentry for SFS TODAY: review existing file system design

Virtual File System Concept Provides an abstract file system interface – Allows higher-level system code to manage a “file” abstraction in a uniform manner, independent of the implementation details of a specific type of file system – Standard system calls such as open, read, write, etc. can be implemented in terms of operations on the abstract file system, rather than having a separate implementation for each real file system – Abstraction layer is for the OS itself It does not provide any additional convenience to the user- level programmer who interacts with the file systems through the system calls

Schematic View of VFS

VFS Design in OS161 VFS layer is essentially an object-oriented design. Basic objects are: – file systems (defined in kern/include/fs.h) – vnodes (defined in kern/include/vnode.h) – vnode is an abstract representation of a file.

Basic objects of VFS Start with the file system objects (fs) – abstract definition of a file system consists of pointers to functions that implement standard operations (sync, getvolname, getroot, and unmount) a pointer to file-system specific data. – A struct vnode is an abstract representation of a file. It is an interface in the Java sense that allows the kernel’s file system-independent code to interact usefully with multiple sets of file system code.

Abstract File System Structure struct fs { // flush all dirty buffers to disk int (*fs_sync)(struct fs *); // Return volume name of file system const char *(*fs_getvolname)(struct fs *); // Return root vnode of file system struct vnode *(*fs_getroot)(struct fs *); // Attempt unmount of file system int (*fs_unmount)(struct fs *); // Pointer to file-system specific data void *fs_data; };

Abstract operations on a vnode vop_read vop_getdirentry vop_write vop_stat vop_gettype …

Implementing a File System An implementation of a specific file system type must provide implementations of functions in abstract file system struct, as well as a “mount” function that can be passed to the abstract vfs_mount routine. The file-system specific mount function must create and initialize an abstract fs structure with pointers to the actual functions implementing the abstract ones. It must also perform any file-system specific initialization that is needed, and fill in the fs_data pointer

Assignment 3 Your primary goals are to complete a set of file-system related system calls and to augment SFS with the ability to read directory entries. – open, close, … – write, getdirentry, … A file descriptor is an index for an entry in a kernel-resident data structure containing the details of all open files.

SFS Implementation See kern/fs/sfs/sfs_fs.c for file system level operations sfs_mount is called from higher-level code to mount sfs (i.e., from the menu) – Calls abstract mount function, vfs_mount, passing a pointer to the sfs-specific mount function, sfs_domount Allows VFS layer to control synchronization if multiple mount commands happen simultaneously

Mount The way mount works is that you call vfs_mount and pass it a file system-specific mount routine. This routine takes a device and hands back a pointer to an abstract file system.

Sfs_domount Initializes an sfs_fs structure(sfs-specific data structure) by reading file system superblock and free space bitmap off disk Initializes abstract file system structure with appropriate function pointers, and sets the fs_data to point to the full sfs_fs structure Returns pointer to abstract fs to VFSlayer Thus, from the abstract file system structure, we can locate the SFS functions that implement basic file system operations, and we can locate the full sfs_fs structure which provides information that those functions will need to do their work.

Relation of sfs_fs to fs structs VFS layer keeps list of “known devices” with a pointer to the abstract file system mounted on each device (if any)

Vnode A vnode is an abstract in-memory representation of a file Mainly provides pointers to code and data for a specific implementation Most importantly, the vnode contains: – A pointer to the abstract file system structure for the file system that stores the file represented by the vnode – A table of function pointers (vn_ops) to the routines that actually implement the standard operations on files for the specific type of file system Operations on files must thus first locate the vnode for the file, and then invoke the requested action by calling a function in the vn_ops table

Vnode in OS161

A3 Hints Open file tables - things need to be tracked both globally and per process – vnode ref count? – Open vnodes a process owns? Read/writeposition? – What happens when process forks?

sys_open We’ll rely on vfs_open to do most of the work. But before that, we need to check: – Is filename a valid pointer? (alignment, NULL, kernel pointer, etc.) – Is flags valid? flags can only contain exactly one of O_RDONLY, O_WRONLY and O_RDWR After these, we need to allocate a fd to the opened file: just scan the curthread->t_fdtable and find a available slot (NULL). Then we need to actually open the file using vfs_open. Once vfs_open successfully returns, we can initialize a struct fdesc.