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 Structurestruct fs {// flush all dirty buffers to diskint (*fs_sync)(struct fs *);// Return volume name of file systemconst char *(*fs_getvolname)(struct fs *);// Return root vnode of file systemstruct vnode *(*fs_getroot)(struct fs *);// Attempt unmount of file systemint (*fs_unmount)(struct fs *);// Pointer to file-system specific datavoid *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.