AOS Lab 10: File system -- Inodes and beyond
-
Upload
zubair-nabi -
Category
Technology
-
view
742 -
download
1
description
Transcript of AOS Lab 10: File system -- Inodes and beyond
Lab 10: File system – Inodes and beyondAdvanced Operating Systems
Zubair Nabi
April 10, 2013
Recap of Lab 9: xv6 FS layers
File descriptors
Recursive lookup
Directory inodes
Inodes and block allocator
Logging
Buffer cache
System calls
Pathnames
Directories
Files
Transactions
Blocks
Recap of Lab 9: xv6 FS layers (2)
1 Buffer cache: Reads and writes blocks on the IDE disk via thebuffer cache, which synchronizes access to disk blocks
• Ensures that only one kernel process can edit any particular blockat a time
2 Logging: Ensures atomicity by enabling higher layers to wrapupdates to several blocks in a transaction
3 Inodes and block allocator: Provides unnamed files, eachunnamed file is represented by an inode and a sequence ofblocks holding the file content
Recap of Lab 9: xv6 FS layers (2)
1 Buffer cache: Reads and writes blocks on the IDE disk via thebuffer cache, which synchronizes access to disk blocks
• Ensures that only one kernel process can edit any particular blockat a time
2 Logging: Ensures atomicity by enabling higher layers to wrapupdates to several blocks in a transaction
3 Inodes and block allocator: Provides unnamed files, eachunnamed file is represented by an inode and a sequence ofblocks holding the file content
Recap of Lab 9: xv6 FS layers (2)
1 Buffer cache: Reads and writes blocks on the IDE disk via thebuffer cache, which synchronizes access to disk blocks
• Ensures that only one kernel process can edit any particular blockat a time
2 Logging: Ensures atomicity by enabling higher layers to wrapupdates to several blocks in a transaction
3 Inodes and block allocator: Provides unnamed files, eachunnamed file is represented by an inode and a sequence ofblocks holding the file content
Recap of Lab 9: xv6 FS layers (2)
1 Buffer cache: Reads and writes blocks on the IDE disk via thebuffer cache, which synchronizes access to disk blocks
• Ensures that only one kernel process can edit any particular blockat a time
2 Logging: Ensures atomicity by enabling higher layers to wrapupdates to several blocks in a transaction
3 Inodes and block allocator: Provides unnamed files, eachunnamed file is represented by an inode and a sequence ofblocks holding the file content
Recap of Lab 9: xv6 FS layers (3)
4 Directory inodes: Implements directories as a special kind ofinode
• The content of this inode is a sequence of directory entries, eachof which contains a name and a reference to the named file’sinode
5 Recursive lookup: Provides hierarchical path names such as/foo/bar/baz.txt, via recursive lookup
6 File descriptors: Abstracts many Unix resources, such as pipes,devices, file, etc., using the file system interface
Recap of Lab 9: xv6 FS layers (3)
4 Directory inodes: Implements directories as a special kind ofinode
• The content of this inode is a sequence of directory entries, eachof which contains a name and a reference to the named file’sinode
5 Recursive lookup: Provides hierarchical path names such as/foo/bar/baz.txt, via recursive lookup
6 File descriptors: Abstracts many Unix resources, such as pipes,devices, file, etc., using the file system interface
Recap of Lab 9: xv6 FS layers (3)
4 Directory inodes: Implements directories as a special kind ofinode
• The content of this inode is a sequence of directory entries, eachof which contains a name and a reference to the named file’sinode
5 Recursive lookup: Provides hierarchical path names such as/foo/bar/baz.txt, via recursive lookup
6 File descriptors: Abstracts many Unix resources, such as pipes,devices, file, etc., using the file system interface
Recap of Lab 9: xv6 FS layers (3)
4 Directory inodes: Implements directories as a special kind ofinode
• The content of this inode is a sequence of directory entries, eachof which contains a name and a reference to the named file’sinode
5 Recursive lookup: Provides hierarchical path names such as/foo/bar/baz.txt, via recursive lookup
6 File descriptors: Abstracts many Unix resources, such as pipes,devices, file, etc., using the file system interface
Recap of Lab 9: File system layout
• xv6 lays out inodes and content blocks on the disk by dividing thedisk into several sections
boot super bitmap... data...inodes... log...
0 1 2 …..
• Block 0 holds the boot sector• Block 1 (called the superblock) contains metadata about the file
system• File system size in blocks, the number of data blocks, the number
of inodes, and the number of blocks in the log
• Blocks starting at 2 hold inodes, with multiple inodes per block
Recap of Lab 9: File system layout
• xv6 lays out inodes and content blocks on the disk by dividing thedisk into several sections
boot super bitmap... data...inodes... log...
0 1 2 …..
• Block 0 holds the boot sector
• Block 1 (called the superblock) contains metadata about the filesystem
• File system size in blocks, the number of data blocks, the numberof inodes, and the number of blocks in the log
• Blocks starting at 2 hold inodes, with multiple inodes per block
Recap of Lab 9: File system layout
• xv6 lays out inodes and content blocks on the disk by dividing thedisk into several sections
boot super bitmap... data...inodes... log...
0 1 2 …..
• Block 0 holds the boot sector• Block 1 (called the superblock) contains metadata about the file
system
• File system size in blocks, the number of data blocks, the numberof inodes, and the number of blocks in the log
• Blocks starting at 2 hold inodes, with multiple inodes per block
Recap of Lab 9: File system layout
• xv6 lays out inodes and content blocks on the disk by dividing thedisk into several sections
boot super bitmap... data...inodes... log...
0 1 2 …..
• Block 0 holds the boot sector• Block 1 (called the superblock) contains metadata about the file
system• File system size in blocks, the number of data blocks, the number
of inodes, and the number of blocks in the log
• Blocks starting at 2 hold inodes, with multiple inodes per block
Recap of Lab 9: File system layout
• xv6 lays out inodes and content blocks on the disk by dividing thedisk into several sections
boot super bitmap... data...inodes... log...
0 1 2 …..
• Block 0 holds the boot sector• Block 1 (called the superblock) contains metadata about the file
system• File system size in blocks, the number of data blocks, the number
of inodes, and the number of blocks in the log
• Blocks starting at 2 hold inodes, with multiple inodes per block
Recap of Lab 9: File system layout
boot super bitmap... data...inodes... log...
0 1 2 …..
• inode blocks are followed by bitmap blocks which keep track ofdata blocks in use
• Bitmap blocks are followed by data blocks which hold file anddirectory contents
• Finally at the end, the blocks hold a log which is required by thetransaction layer
Recap of Lab 9: File system layout
boot super bitmap... data...inodes... log...
0 1 2 …..
• inode blocks are followed by bitmap blocks which keep track ofdata blocks in use
• Bitmap blocks are followed by data blocks which hold file anddirectory contents
• Finally at the end, the blocks hold a log which is required by thetransaction layer
Recap of Lab 9: File system layout
boot super bitmap... data...inodes... log...
0 1 2 …..
• inode blocks are followed by bitmap blocks which keep track ofdata blocks in use
• Bitmap blocks are followed by data blocks which hold file anddirectory contents
• Finally at the end, the blocks hold a log which is required by thetransaction layer
Inodes
• Have two variants:1 On-disk data structure containing a file’s size and list of data block
numbers
2 In-memory version of the on-disk inode, along with extrainformation needed within the kernel
• All on-disk inodes are stored in a contiguous area of disk,between the superblock and the bitmap block
• Each inode has the same size, so given a number n (called theinode number or i-number), it is simple to locate thecorresponding inode
Inodes
• Have two variants:1 On-disk data structure containing a file’s size and list of data block
numbers2 In-memory version of the on-disk inode, along with extra
information needed within the kernel
• All on-disk inodes are stored in a contiguous area of disk,between the superblock and the bitmap block
• Each inode has the same size, so given a number n (called theinode number or i-number), it is simple to locate thecorresponding inode
Inodes
• Have two variants:1 On-disk data structure containing a file’s size and list of data block
numbers2 In-memory version of the on-disk inode, along with extra
information needed within the kernel
• All on-disk inodes are stored in a contiguous area of disk,between the superblock and the bitmap block
• Each inode has the same size, so given a number n (called theinode number or i-number), it is simple to locate thecorresponding inode
Inodes
• Have two variants:1 On-disk data structure containing a file’s size and list of data block
numbers2 In-memory version of the on-disk inode, along with extra
information needed within the kernel
• All on-disk inodes are stored in a contiguous area of disk,between the superblock and the bitmap block
• Each inode has the same size, so given a number n (called theinode number or i-number), it is simple to locate thecorresponding inode
On-disk inodes
• Represented by struct dinode
• Contains a type field to distinguish between files, directories, andspecial files (devices)
• Zero indicates that the dinode is free
• Also keeps track of the number of directory entries that refer tothis inode
• This reference count dictates when the inode should be freed
• Also has fields to hold number of bytes of content and the blocknumbers of disk blocks
On-disk inodes
• Represented by struct dinode
• Contains a type field to distinguish between files, directories, andspecial files (devices)
• Zero indicates that the dinode is free
• Also keeps track of the number of directory entries that refer tothis inode
• This reference count dictates when the inode should be freed
• Also has fields to hold number of bytes of content and the blocknumbers of disk blocks
On-disk inodes
• Represented by struct dinode
• Contains a type field to distinguish between files, directories, andspecial files (devices)
• Zero indicates that the dinode is free
• Also keeps track of the number of directory entries that refer tothis inode
• This reference count dictates when the inode should be freed
• Also has fields to hold number of bytes of content and the blocknumbers of disk blocks
On-disk inodes
• Represented by struct dinode
• Contains a type field to distinguish between files, directories, andspecial files (devices)
• Zero indicates that the dinode is free
• Also keeps track of the number of directory entries that refer tothis inode
• This reference count dictates when the inode should be freed
• Also has fields to hold number of bytes of content and the blocknumbers of disk blocks
On-disk inodes
• Represented by struct dinode
• Contains a type field to distinguish between files, directories, andspecial files (devices)
• Zero indicates that the dinode is free
• Also keeps track of the number of directory entries that refer tothis inode
• This reference count dictates when the inode should be freed
• Also has fields to hold number of bytes of content and the blocknumbers of disk blocks
On-disk inodes
• Represented by struct dinode
• Contains a type field to distinguish between files, directories, andspecial files (devices)
• Zero indicates that the dinode is free
• Also keeps track of the number of directory entries that refer tothis inode
• This reference count dictates when the inode should be freed
• Also has fields to hold number of bytes of content and the blocknumbers of disk blocks
Code: dinode
struct dinode {short type; // File typeshort major; // Major device number (T_DEV only)short minor; // Minor device number (T_DEV only)short nlink; // Number of links to inode in file systemuint size; // Size of file (bytes)uint addrs[NDIRECT+1]; // Data block addresses
};#define T_DIR 1 // Directory#define T_FILE 2 // File#define T_DEV 3 // Device
In-memory inodes
• Represented by struct inode
• An inode is kept in memory if there are C pointers referring to it• These pointers come from file descriptors, current working
directories, and kernel code• iget and iput functions are used to acquire and release
pointers to/from an inode• A pointer via an iget() call implements a weak form of a lock by
ensuring that the inode will stay in the cache till the referencecount goes down to zero
• These pointers enable long-term references (open files andcurrent directory) and to prevent deadlock in code thatmanipulates multiple inodes (pathname lookup)
In-memory inodes
• Represented by struct inode
• An inode is kept in memory if there are C pointers referring to it
• These pointers come from file descriptors, current workingdirectories, and kernel code
• iget and iput functions are used to acquire and releasepointers to/from an inode
• A pointer via an iget() call implements a weak form of a lock byensuring that the inode will stay in the cache till the referencecount goes down to zero
• These pointers enable long-term references (open files andcurrent directory) and to prevent deadlock in code thatmanipulates multiple inodes (pathname lookup)
In-memory inodes
• Represented by struct inode
• An inode is kept in memory if there are C pointers referring to it• These pointers come from file descriptors, current working
directories, and kernel code
• iget and iput functions are used to acquire and releasepointers to/from an inode
• A pointer via an iget() call implements a weak form of a lock byensuring that the inode will stay in the cache till the referencecount goes down to zero
• These pointers enable long-term references (open files andcurrent directory) and to prevent deadlock in code thatmanipulates multiple inodes (pathname lookup)
In-memory inodes
• Represented by struct inode
• An inode is kept in memory if there are C pointers referring to it• These pointers come from file descriptors, current working
directories, and kernel code• iget and iput functions are used to acquire and release
pointers to/from an inode
• A pointer via an iget() call implements a weak form of a lock byensuring that the inode will stay in the cache till the referencecount goes down to zero
• These pointers enable long-term references (open files andcurrent directory) and to prevent deadlock in code thatmanipulates multiple inodes (pathname lookup)
In-memory inodes
• Represented by struct inode
• An inode is kept in memory if there are C pointers referring to it• These pointers come from file descriptors, current working
directories, and kernel code• iget and iput functions are used to acquire and release
pointers to/from an inode• A pointer via an iget() call implements a weak form of a lock by
ensuring that the inode will stay in the cache till the referencecount goes down to zero
• These pointers enable long-term references (open files andcurrent directory) and to prevent deadlock in code thatmanipulates multiple inodes (pathname lookup)
In-memory inodes
• Represented by struct inode
• An inode is kept in memory if there are C pointers referring to it• These pointers come from file descriptors, current working
directories, and kernel code• iget and iput functions are used to acquire and release
pointers to/from an inode• A pointer via an iget() call implements a weak form of a lock by
ensuring that the inode will stay in the cache till the referencecount goes down to zero
• These pointers enable long-term references (open files andcurrent directory) and to prevent deadlock in code thatmanipulates multiple inodes (pathname lookup)
Code: inode
struct inode {uint dev; // Device numberuint inum; // Inode numberint ref; // Reference countint flags; // I_BUSY, I_VALID
short type; // copy of disk inodeshort major;short minor;short nlink;uint size;uint addrs[NDIRECT+1];
};#define I_BUSY 0x1#define I_VALID 0x2
Inode locks and allocation
• To ensure that an inode has valid content, the code must read itfrom disk
• This read call must be wrapped around ilock and iunlock
• This allows multiple processes to hold a C pointer to an inode butonly one process can lock it at a time
• Inodes are allocated via ialloc which works similar to balloc
Inode locks and allocation
• To ensure that an inode has valid content, the code must read itfrom disk
• This read call must be wrapped around ilock and iunlock
• This allows multiple processes to hold a C pointer to an inode butonly one process can lock it at a time
• Inodes are allocated via ialloc which works similar to balloc
Inode locks and allocation
• To ensure that an inode has valid content, the code must read itfrom disk
• This read call must be wrapped around ilock and iunlock
• This allows multiple processes to hold a C pointer to an inode butonly one process can lock it at a time
• Inodes are allocated via ialloc which works similar to balloc
Inode locks and allocation
• To ensure that an inode has valid content, the code must read itfrom disk
• This read call must be wrapped around ilock and iunlock
• This allows multiple processes to hold a C pointer to an inode butonly one process can lock it at a time
• Inodes are allocated via ialloc which works similar to balloc
Inode data
• Data is found in the blocks pointed to by the addrs fields
• Size of addrs is NDIRECT+1 where NDIRECT is 12
• addrs can refer to 6KB of data
• The 13th location in addrs field points to the indirect block(NINDIRECT) which points to 64KB of data
• Therefore, while fixed-sized blocks simplify look up, the maximumsize of a file in xv6 can be 70KB
Inode data
• Data is found in the blocks pointed to by the addrs fields
• Size of addrs is NDIRECT+1 where NDIRECT is 12
• addrs can refer to 6KB of data
• The 13th location in addrs field points to the indirect block(NINDIRECT) which points to 64KB of data
• Therefore, while fixed-sized blocks simplify look up, the maximumsize of a file in xv6 can be 70KB
Inode data
• Data is found in the blocks pointed to by the addrs fields
• Size of addrs is NDIRECT+1 where NDIRECT is 12
• addrs can refer to 6KB of data
• The 13th location in addrs field points to the indirect block(NINDIRECT) which points to 64KB of data
• Therefore, while fixed-sized blocks simplify look up, the maximumsize of a file in xv6 can be 70KB
Inode data
• Data is found in the blocks pointed to by the addrs fields
• Size of addrs is NDIRECT+1 where NDIRECT is 12
• addrs can refer to 6KB of data
• The 13th location in addrs field points to the indirect block(NINDIRECT) which points to 64KB of data
• Therefore, while fixed-sized blocks simplify look up, the maximumsize of a file in xv6 can be 70KB
Inode data
• Data is found in the blocks pointed to by the addrs fields
• Size of addrs is NDIRECT+1 where NDIRECT is 12
• addrs can refer to 6KB of data
• The 13th location in addrs field points to the indirect block(NINDIRECT) which points to 64KB of data
• Therefore, while fixed-sized blocks simplify look up, the maximumsize of a file in xv6 can be 70KB
Inodes content
• bmap(struct inode *ip, uint bn) returns the diskaddress of the nth block within inode ip, masking away thecomplexity of direct and indirect blocks
• If the data block does not exist, it is created
• itrunc(struct inode *ip) frees inode ip by setting itsreference count to zero and freeing up blocks, both direct andindirect
• readi(struct inode *ip, char *dst, uintoff, uint n) reads n blocks in inode ip starting from offinto dst
Inodes content
• bmap(struct inode *ip, uint bn) returns the diskaddress of the nth block within inode ip, masking away thecomplexity of direct and indirect blocks
• If the data block does not exist, it is created
• itrunc(struct inode *ip) frees inode ip by setting itsreference count to zero and freeing up blocks, both direct andindirect
• readi(struct inode *ip, char *dst, uintoff, uint n) reads n blocks in inode ip starting from offinto dst
Inodes content
• bmap(struct inode *ip, uint bn) returns the diskaddress of the nth block within inode ip, masking away thecomplexity of direct and indirect blocks
• If the data block does not exist, it is created
• itrunc(struct inode *ip) frees inode ip by setting itsreference count to zero and freeing up blocks, both direct andindirect
• readi(struct inode *ip, char *dst, uintoff, uint n) reads n blocks in inode ip starting from offinto dst
Inodes content
• bmap(struct inode *ip, uint bn) returns the diskaddress of the nth block within inode ip, masking away thecomplexity of direct and indirect blocks
• If the data block does not exist, it is created
• itrunc(struct inode *ip) frees inode ip by setting itsreference count to zero and freeing up blocks, both direct andindirect
• readi(struct inode *ip, char *dst, uintoff, uint n) reads n blocks in inode ip starting from offinto dst
Inodes content (2)
• writei(struct inode *ip, char *src, uintoff, uint n) works similar to readi but it:
1 Copies data in instead of out2 Extends the file if the write increases its size3 Updates the size in the inode
• stati(struct inode *ip, struct stat *st)copies metadata of inode ip into st which is exposed touserspace via the stat system call
Inodes content (2)
• writei(struct inode *ip, char *src, uintoff, uint n) works similar to readi but it:
1 Copies data in instead of out
2 Extends the file if the write increases its size3 Updates the size in the inode
• stati(struct inode *ip, struct stat *st)copies metadata of inode ip into st which is exposed touserspace via the stat system call
Inodes content (2)
• writei(struct inode *ip, char *src, uintoff, uint n) works similar to readi but it:
1 Copies data in instead of out2 Extends the file if the write increases its size
3 Updates the size in the inode
• stati(struct inode *ip, struct stat *st)copies metadata of inode ip into st which is exposed touserspace via the stat system call
Inodes content (2)
• writei(struct inode *ip, char *src, uintoff, uint n) works similar to readi but it:
1 Copies data in instead of out2 Extends the file if the write increases its size3 Updates the size in the inode
• stati(struct inode *ip, struct stat *st)copies metadata of inode ip into st which is exposed touserspace via the stat system call
Inodes content (2)
• writei(struct inode *ip, char *src, uintoff, uint n) works similar to readi but it:
1 Copies data in instead of out2 Extends the file if the write increases its size3 Updates the size in the inode
• stati(struct inode *ip, struct stat *st)copies metadata of inode ip into st which is exposed touserspace via the stat system call
Directory layer
• A directory is a file with an inode type T_DIR and data in theform of a sequence of directory entries
• Each entry is a struct dirent
struct dirent {ushort inum; // free, if zerochar name[DIRSIZ];
};#define DIRSIZ 14
Directory layer
• A directory is a file with an inode type T_DIR and data in theform of a sequence of directory entries
• Each entry is a struct dirent
struct dirent {ushort inum; // free, if zerochar name[DIRSIZ];
};#define DIRSIZ 14
Directory layer
• A directory is a file with an inode type T_DIR and data in theform of a sequence of directory entries
• Each entry is a struct dirent
struct dirent {ushort inum; // free, if zerochar name[DIRSIZ];
};#define DIRSIZ 14
dirlookup
• Searches a directory for an entry with the given name
• Signature: struct inode* dirlookup(struct inode
*dp, char *name, uint *poff)
• If it finds it, it returns a pointer to the corresponding inode viaiget, unlocked, and returns the offset of the entry within thedirectory
dirlookup
• Searches a directory for an entry with the given name
• Signature: struct inode* dirlookup(struct inode
*dp, char *name, uint *poff)
• If it finds it, it returns a pointer to the corresponding inode viaiget, unlocked, and returns the offset of the entry within thedirectory
dirlookup
• Searches a directory for an entry with the given name
• Signature: struct inode* dirlookup(struct inode
*dp, char *name, uint *poff)
• If it finds it, it returns a pointer to the corresponding inode viaiget, unlocked, and returns the offset of the entry within thedirectory
dirlink
• Writes a new directory entry with the given name and inodenumber into dp
• Signature: int dirlink(struct inode *dp, char
*name, uint inum)
dirlink
• Writes a new directory entry with the given name and inodenumber into dp
• Signature: int dirlink(struct inode *dp, char
*name, uint inum)
Path names
• Path name look up is enabled by multiple calls – one for eachpath component – to dirlookup
• namei takes a path and returns the corresponding inode
• nameiparent is similar but returns the inode of the parentdirectory
• Both make a call to namex internally
Path names
• Path name look up is enabled by multiple calls – one for eachpath component – to dirlookup
• namei takes a path and returns the corresponding inode
• nameiparent is similar but returns the inode of the parentdirectory
• Both make a call to namex internally
Path names
• Path name look up is enabled by multiple calls – one for eachpath component – to dirlookup
• namei takes a path and returns the corresponding inode
• nameiparent is similar but returns the inode of the parentdirectory
• Both make a call to namex internally
Path names
• Path name look up is enabled by multiple calls – one for eachpath component – to dirlookup
• namei takes a path and returns the corresponding inode
• nameiparent is similar but returns the inode of the parentdirectory
• Both make a call to namex internally
namex
• Starts by deciding where the path evaluation begins
• If the path begins with /, evaluation starts at the root• Otherwise, the current directory
• Uses skipelem to parse the path into path elements
• For each iteration (depending on the number of path elements),looks up name within the current path element inode till it findsthe required inode and returns it
namex
• Starts by deciding where the path evaluation begins• If the path begins with /, evaluation starts at the root
• Otherwise, the current directory
• Uses skipelem to parse the path into path elements
• For each iteration (depending on the number of path elements),looks up name within the current path element inode till it findsthe required inode and returns it
namex
• Starts by deciding where the path evaluation begins• If the path begins with /, evaluation starts at the root• Otherwise, the current directory
• Uses skipelem to parse the path into path elements
• For each iteration (depending on the number of path elements),looks up name within the current path element inode till it findsthe required inode and returns it
namex
• Starts by deciding where the path evaluation begins• If the path begins with /, evaluation starts at the root• Otherwise, the current directory
• Uses skipelem to parse the path into path elements
• For each iteration (depending on the number of path elements),looks up name within the current path element inode till it findsthe required inode and returns it
namex
• Starts by deciding where the path evaluation begins• If the path begins with /, evaluation starts at the root• Otherwise, the current directory
• Uses skipelem to parse the path into path elements
• For each iteration (depending on the number of path elements),looks up name within the current path element inode till it findsthe required inode and returns it
File descriptor layer
• Everything in Unix is a file and this interface is enabled by the filedescriptor layer
• Each process has its own open files (or file descriptor) table
• Each open file is represented by struct file
File descriptor layer
• Everything in Unix is a file and this interface is enabled by the filedescriptor layer
• Each process has its own open files (or file descriptor) table
• Each open file is represented by struct file
File descriptor layer
• Everything in Unix is a file and this interface is enabled by the filedescriptor layer
• Each process has its own open files (or file descriptor) table
• Each open file is represented by struct file
Code: struct file
struct file {enum { FD_NONE, FD_PIPE, FD_INODE } type;int ref; // reference countchar readable;char writable;struct pipe *pipe;struct inode *ip;uint off;
};
file
• struct file is simply a wrapper around an inode or a pipe;plus an I/O offset
• Each call to open creates a new struct file• If multiple processes open the same independently, they will have
their own struct file for it with a local I/O offset• The same struct file can appear multiple times within a) A
process’s file table, and b) Across multiple processes• When would this happen?• a happens when a process opens a file and then dups it and b
takes place when it makes a call to fork
• Reference count tracks the number of references to a particularopen file
• Read/write access is tracked by readable/writable fields
file
• struct file is simply a wrapper around an inode or a pipe;plus an I/O offset
• Each call to open creates a new struct file
• If multiple processes open the same independently, they will havetheir own struct file for it with a local I/O offset
• The same struct file can appear multiple times within a) Aprocess’s file table, and b) Across multiple processes
• When would this happen?• a happens when a process opens a file and then dups it and b
takes place when it makes a call to fork
• Reference count tracks the number of references to a particularopen file
• Read/write access is tracked by readable/writable fields
file
• struct file is simply a wrapper around an inode or a pipe;plus an I/O offset
• Each call to open creates a new struct file• If multiple processes open the same independently, they will have
their own struct file for it with a local I/O offset
• The same struct file can appear multiple times within a) Aprocess’s file table, and b) Across multiple processes
• When would this happen?• a happens when a process opens a file and then dups it and b
takes place when it makes a call to fork
• Reference count tracks the number of references to a particularopen file
• Read/write access is tracked by readable/writable fields
file
• struct file is simply a wrapper around an inode or a pipe;plus an I/O offset
• Each call to open creates a new struct file• If multiple processes open the same independently, they will have
their own struct file for it with a local I/O offset• The same struct file can appear multiple times within a) A
process’s file table, and b) Across multiple processes
• When would this happen?• a happens when a process opens a file and then dups it and b
takes place when it makes a call to fork
• Reference count tracks the number of references to a particularopen file
• Read/write access is tracked by readable/writable fields
file
• struct file is simply a wrapper around an inode or a pipe;plus an I/O offset
• Each call to open creates a new struct file• If multiple processes open the same independently, they will have
their own struct file for it with a local I/O offset• The same struct file can appear multiple times within a) A
process’s file table, and b) Across multiple processes• When would this happen?
• a happens when a process opens a file and then dups it and btakes place when it makes a call to fork
• Reference count tracks the number of references to a particularopen file
• Read/write access is tracked by readable/writable fields
file
• struct file is simply a wrapper around an inode or a pipe;plus an I/O offset
• Each call to open creates a new struct file• If multiple processes open the same independently, they will have
their own struct file for it with a local I/O offset• The same struct file can appear multiple times within a) A
process’s file table, and b) Across multiple processes• When would this happen?• a happens when a process opens a file and then dups it and b
takes place when it makes a call to fork
• Reference count tracks the number of references to a particularopen file
• Read/write access is tracked by readable/writable fields
file
• struct file is simply a wrapper around an inode or a pipe;plus an I/O offset
• Each call to open creates a new struct file• If multiple processes open the same independently, they will have
their own struct file for it with a local I/O offset• The same struct file can appear multiple times within a) A
process’s file table, and b) Across multiple processes• When would this happen?• a happens when a process opens a file and then dups it and b
takes place when it makes a call to fork
• Reference count tracks the number of references to a particularopen file
• Read/write access is tracked by readable/writable fields
file
• struct file is simply a wrapper around an inode or a pipe;plus an I/O offset
• Each call to open creates a new struct file• If multiple processes open the same independently, they will have
their own struct file for it with a local I/O offset• The same struct file can appear multiple times within a) A
process’s file table, and b) Across multiple processes• When would this happen?• a happens when a process opens a file and then dups it and b
takes place when it makes a call to fork
• Reference count tracks the number of references to a particularopen file
• Read/write access is tracked by readable/writable fields
Global file table
• All open files in the system are kept within a global file table(ftable)
• ftable has corresponding functions to:1 Allocate a file: filealloc2 Create a duplicate reference: filedup3 Release a reference: fileclose4 Read from a file: fileread5 Write to a file: filewrite
Global file table
• All open files in the system are kept within a global file table(ftable)
• ftable has corresponding functions to:1 Allocate a file: filealloc
2 Create a duplicate reference: filedup3 Release a reference: fileclose4 Read from a file: fileread5 Write to a file: filewrite
Global file table
• All open files in the system are kept within a global file table(ftable)
• ftable has corresponding functions to:1 Allocate a file: filealloc2 Create a duplicate reference: filedup
3 Release a reference: fileclose4 Read from a file: fileread5 Write to a file: filewrite
Global file table
• All open files in the system are kept within a global file table(ftable)
• ftable has corresponding functions to:1 Allocate a file: filealloc2 Create a duplicate reference: filedup3 Release a reference: fileclose
4 Read from a file: fileread5 Write to a file: filewrite
Global file table
• All open files in the system are kept within a global file table(ftable)
• ftable has corresponding functions to:1 Allocate a file: filealloc2 Create a duplicate reference: filedup3 Release a reference: fileclose4 Read from a file: fileread
5 Write to a file: filewrite
Global file table
• All open files in the system are kept within a global file table(ftable)
• ftable has corresponding functions to:1 Allocate a file: filealloc2 Create a duplicate reference: filedup3 Release a reference: fileclose4 Read from a file: fileread5 Write to a file: filewrite
File manipulation
• filealloc: Scans the file table for an unreferenced file(f->ref == 0) and returns a new reference
• filedup: Increments the reference count• fileclose: Decrements the reference count
• If f->ref == 0, underlying pipe or inode is released
File manipulation
• filealloc: Scans the file table for an unreferenced file(f->ref == 0) and returns a new reference
• filedup: Increments the reference count
• fileclose: Decrements the reference count• If f->ref == 0, underlying pipe or inode is released
File manipulation
• filealloc: Scans the file table for an unreferenced file(f->ref == 0) and returns a new reference
• filedup: Increments the reference count• fileclose: Decrements the reference count
• If f->ref == 0, underlying pipe or inode is released
File manipulation
• filealloc: Scans the file table for an unreferenced file(f->ref == 0) and returns a new reference
• filedup: Increments the reference count• fileclose: Decrements the reference count
• If f->ref == 0, underlying pipe or inode is released
File manipulation (2)
• filestat: Invokes stati and ensures that the file representsan inode
• fileread and filewrite:1 Check whether the operation is allowed by the open mode2 Patch the call through to either the underlying pipe or inode
implementation3 If the wrapper is around an inode, the I/O offset would be used
and then advanced4 Pipes have no concept of offset
File manipulation (2)
• filestat: Invokes stati and ensures that the file representsan inode
• fileread and filewrite:1 Check whether the operation is allowed by the open mode
2 Patch the call through to either the underlying pipe or inodeimplementation
3 If the wrapper is around an inode, the I/O offset would be usedand then advanced
4 Pipes have no concept of offset
File manipulation (2)
• filestat: Invokes stati and ensures that the file representsan inode
• fileread and filewrite:1 Check whether the operation is allowed by the open mode2 Patch the call through to either the underlying pipe or inode
implementation
3 If the wrapper is around an inode, the I/O offset would be usedand then advanced
4 Pipes have no concept of offset
File manipulation (2)
• filestat: Invokes stati and ensures that the file representsan inode
• fileread and filewrite:1 Check whether the operation is allowed by the open mode2 Patch the call through to either the underlying pipe or inode
implementation3 If the wrapper is around an inode, the I/O offset would be used
and then advanced
4 Pipes have no concept of offset
File manipulation (2)
• filestat: Invokes stati and ensures that the file representsan inode
• fileread and filewrite:1 Check whether the operation is allowed by the open mode2 Patch the call through to either the underlying pipe or inode
implementation3 If the wrapper is around an inode, the I/O offset would be used
and then advanced4 Pipes have no concept of offset
System calls
• sys_link and sys_unlink edit directories by creating orremoving references to inodes
• sys_link creates a new name for an existing inode1 Takes as arguments two strings old and new2 Increments its nlink field – Number of links3 Creates a new directory entry pointing at old’s inode4 The new directory entry is on the same inode as the existing one
System calls
• sys_link and sys_unlink edit directories by creating orremoving references to inodes
• sys_link creates a new name for an existing inode
1 Takes as arguments two strings old and new2 Increments its nlink field – Number of links3 Creates a new directory entry pointing at old’s inode4 The new directory entry is on the same inode as the existing one
System calls
• sys_link and sys_unlink edit directories by creating orremoving references to inodes
• sys_link creates a new name for an existing inode1 Takes as arguments two strings old and new
2 Increments its nlink field – Number of links3 Creates a new directory entry pointing at old’s inode4 The new directory entry is on the same inode as the existing one
System calls
• sys_link and sys_unlink edit directories by creating orremoving references to inodes
• sys_link creates a new name for an existing inode1 Takes as arguments two strings old and new2 Increments its nlink field – Number of links
3 Creates a new directory entry pointing at old’s inode4 The new directory entry is on the same inode as the existing one
System calls
• sys_link and sys_unlink edit directories by creating orremoving references to inodes
• sys_link creates a new name for an existing inode1 Takes as arguments two strings old and new2 Increments its nlink field – Number of links3 Creates a new directory entry pointing at old’s inode
4 The new directory entry is on the same inode as the existing one
System calls
• sys_link and sys_unlink edit directories by creating orremoving references to inodes
• sys_link creates a new name for an existing inode1 Takes as arguments two strings old and new2 Increments its nlink field – Number of links3 Creates a new directory entry pointing at old’s inode4 The new directory entry is on the same inode as the existing one
create
• Creates a new name for a new inode
• Generalizes the creation of three file creation system calls:1 open with the O_CREATE flag creates a new file2 mkdir creates a new directory3 mkdev creates a new device file
create
• Creates a new name for a new inode• Generalizes the creation of three file creation system calls:
1 open with the O_CREATE flag creates a new file2 mkdir creates a new directory3 mkdev creates a new device file
create
• Creates a new name for a new inode• Generalizes the creation of three file creation system calls:
1 open with the O_CREATE flag creates a new file
2 mkdir creates a new directory3 mkdev creates a new device file
create
• Creates a new name for a new inode• Generalizes the creation of three file creation system calls:
1 open with the O_CREATE flag creates a new file2 mkdir creates a new directory
3 mkdev creates a new device file
create
• Creates a new name for a new inode• Generalizes the creation of three file creation system calls:
1 open with the O_CREATE flag creates a new file2 mkdir creates a new directory3 mkdev creates a new device file
create (2)
• Makes a call to dirlookup to check whether the name alreadyexists
• If it does not exist, creates a new inode via a call to ialloc
• If create has been invoked by mkdir (T_DIR), it initializes itwith . and .. entries
• Finally, it links it into the parent directory
create (2)
• Makes a call to dirlookup to check whether the name alreadyexists
• If it does not exist, creates a new inode via a call to ialloc
• If create has been invoked by mkdir (T_DIR), it initializes itwith . and .. entries
• Finally, it links it into the parent directory
create (2)
• Makes a call to dirlookup to check whether the name alreadyexists
• If it does not exist, creates a new inode via a call to ialloc
• If create has been invoked by mkdir (T_DIR), it initializes itwith . and .. entries
• Finally, it links it into the parent directory
create (2)
• Makes a call to dirlookup to check whether the name alreadyexists
• If it does not exist, creates a new inode via a call to ialloc
• If create has been invoked by mkdir (T_DIR), it initializes itwith . and .. entries
• Finally, it links it into the parent directory
Buffer cache eviction policy
• xv6’s buffer cache uses simple LRU eviction
• A number of different policies can be implemented such as FIFO,not frequently used, aging, random, etc.
• The buffer cache is currently a linked list but an efficientimplementation can replace it with a hash table and/or a heap
• The buffer cache can also be integrated with the virtual memorysystem to enabled memory-mapped files (mmap in Linux)
Buffer cache eviction policy
• xv6’s buffer cache uses simple LRU eviction
• A number of different policies can be implemented such as FIFO,not frequently used, aging, random, etc.
• The buffer cache is currently a linked list but an efficientimplementation can replace it with a hash table and/or a heap
• The buffer cache can also be integrated with the virtual memorysystem to enabled memory-mapped files (mmap in Linux)
Buffer cache eviction policy
• xv6’s buffer cache uses simple LRU eviction
• A number of different policies can be implemented such as FIFO,not frequently used, aging, random, etc.
• The buffer cache is currently a linked list but an efficientimplementation can replace it with a hash table and/or a heap
• The buffer cache can also be integrated with the virtual memorysystem to enabled memory-mapped files (mmap in Linux)
Buffer cache eviction policy
• xv6’s buffer cache uses simple LRU eviction
• A number of different policies can be implemented such as FIFO,not frequently used, aging, random, etc.
• The buffer cache is currently a linked list but an efficientimplementation can replace it with a hash table and/or a heap
• The buffer cache can also be integrated with the virtual memorysystem to enabled memory-mapped files (mmap in Linux)
Today’s task
• xv6 has no support for memory-mapped files
• Come up with a design to implement mmap1
1http://man7.org/linux/man-pages/man2/mmap.2.html
Reading(s)
• Chapter 6, “File system”, from “Code: directory layer" onwardsfrom “xv6: a simple, Unix-like teaching operating system”