Transcript A3_Reviewx

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 userlevel 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.