Update of /cvsroot/bsdbook/bsdbook/src
In directory usw-pr-cvs1:/tmp/cvs-serv10264
Modified Files:
filesys.tex
Log Message:
vfs continuation
Index: filesys.tex
===================================================================
RCS file: /cvsroot/bsdbook/bsdbook/src/filesys.tex,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -d -r1.1 -r1.2
--- filesys.tex 28 Aug 2002 11:02:28 -0000 1.1
+++ filesys.tex 29 Aug 2002 15:10:14 -0000 1.2
@@ -98,6 +98,11 @@
with small fixed inode size. It should be mentioned, that this solutuion
is used in some modern filesystem, such as linux's ext2 filesystem.
+User processes access a files by giving the filename. They don't care about
+the inodes. In order to convert the filename into appropriate inode,
+a special action called 'name lookup' should be done. This action is
+performed by kernel function namei().
+
SUBSECTION: The superblock
@@ -165,6 +170,41 @@
file size for a directory. As a result, directory sizes are never reduced.
+SUBSECTION: Userland - Kernelland interaction
+
+Now let's figure out, what happened under the hood, when user application
+issues 'open' system call in order to open a file.
+
+ o User process issues open() system call, giving the pathname and
+ desired attributes.
+
+ o System call swithes the execution mode, and now process starts to
+ execute kernel code. the open() system call hadler calls namei()
+ function to get the inode for the requested file. The namei()
+ function allocates the new inode if needed and puts it into global
+ inode table. Also a record in other system structure is made, called
+ system file table. System file table contains the records
+ of every file used by a system at the moment. Each record maintains
+ the file pointer, file access mode, and pointer to inode.
+
+ o Every process has its own file table. This is just an array of
+ pointers in U-area. Each element points to a record in system file
+ table, or is NULL. So file descriptor, returned by an open() system
+ call, is just an index in that file table. If process opens a new file,
+ it scans its file table for a NULL pointer (i.e., free slot), puts
+ the pointer to a system file table record there, and returns an index.
+ The size of file table determines the maximum number of files that
+ can be opened by a process.
+
+ o The open() system call returns and integer value which is an index
+ in the process's file table.
+
+So the file descriptor is meaningful only in the process context.
+Next, if the process issues read() or write() system call, the kernel
+will know which file to operate on by looking into process' file table and
+following the pointer indexed by a file descriptor.
+
+
SUBSECTION: Weaknesses of s5fs filesystem
@@ -188,3 +228,62 @@
Second is the abstraction of inode. The associated methods represent all
the actions may have been taken over the file object.
+Following this architecture, the filesystem in modern UNIX OS:
+
+ o from user point of view, is a set of files organized in
+ a hierarchical tree. Files of special types - directories - plays
+ a role of containers for the files of other types and other
+ directories. The hierarchical structure has single root,
+ and may consist of several subtrees. Each subtree is an independent
+ filesystem, and it becomes a part of a tree by performing
+ a 'mount' action. A subtree can be mounted on any directory
+ in main tree. Since those subtrees are independent, inode numbering
+ is independent in each of them.
+
+ o from user application point of view, a filesystem is a set of
+ file descriptors opened by a process. In other words, it is
+ simply an array of integers. Process may use them as parameters to
+ limited set of filesystem-related system calls such as 'open',
+ 'write' etc.
+
+ o from kernel point of view, filesystem is a list of vnodes.
+
+SUBSECTION: vnode and vnode operations
+
+So the vnode is the key element for VFS. Vnodes are fully in-memory objects,
+there are no on-disk structures associated with them. The relationship between
+vnode, in-core inode and on-disk inode is as follows:
+ vnode -> in-core inode -> on-disk inode
+Vnode is filesystem-independent object, and it 'references' the
+filesystem-dependent inode object, which is the 'copy' of appropriate on-disk
+inode object. When process requests a file, the kernel allocates new vnode
+object for that. When file is released, it deallocates the vnode object. To
+speed up those operations, the vnode cache is maintained by the kernel.
+
+One vnode is resident in kernel memory permanently: this is the vnode for
+the root of the filesystem.
+
+
+SUBSECTION: VFS operations
+
+When a user process makes a system call that operates on filesystem in
+general, the kernel calls the appropriate VFS function. VFS function,
+naturally, points to a underlying 'real' filesystem's function.
+Here is the list of vfsops methods, and associated system calls:
+
+ Method System Call
+
+ vfs_mount mount
+ vfs_start -
+ vfs_unmount unmount
+ vfs_root -
+ vfs_quotactl quotactl
+ vfs_statfs statfs
+ vfs_sync sync
+ vfs_vget -
+ vfs_fhtovp -
+ vfs_checkexp -
+ vfs_vptofh -
+ vfs_init -
+ vfs_uninit -
+ vfs_extattrctl -
|
