操作系统专业课程设计.docx

虚拟文件系统和虚拟数据库管理系统
【目录】
一，虚拟文件系统
1.1 文件系统总体结构
1.2 实现VFS关键数据结构
1.2.1超级块（superblock）对象
1.2.2索引节点（inode）对象
1.2.3 目录项（dentry）对象
1.2.4文件(file)对象

二，虚拟数据库管理系统
2.1 虚拟数据库
2.2，虚拟数据库管理系统系统结构图
2.3、虚拟数据库查询处理过程
2.4 虚拟数据库管理系统关键技术—模式集成
三，虚拟数据库管理系统和文件管理系统对比
3.1，VFS中物理系统及设备——VDBMS中数据源：
3.2，VFS中超级块读译函数和索引节点——VDBMS中包装器和抽取器
3.3，VFS中超级块节点对应关系——VDBMS中VDB服务器
3.4，虚拟文件系统和虚拟数据库管理系统区分

【摘要】本文分别叙述了虚拟文件系统和虚拟数据库管理系统，并并对二者基础思想和系统结构进行比较。
【关键词】虚拟 文件系统 数据库管理系统
【正文】在信息高速发展今天，信息量越来越大。在计算机中，信息是以文件形式存在，怎样处理信息对使用计算机和因特网人来说就是怎样处理文件。就现在来说，最普及处理信息方法是经过文件系统和数据库系统。
一． 虚拟文件系统
1.1 文件系统总体结构
文件物理结构
文件格式
文件逻辑结构
在计算机中，文件结构是文件内容组织方法。从不一样层面上看到文件结构有所不一样。

文件系统负责文件逻辑结构和物理结构之间相互映射。文件逻辑结构有统计式文件和流式文件。文件物理结构有次序文件，索引文件和链接文件。下面是linux文件系统结构：

I节点缓存
目录项缓存
设备驱动程序
缓冲区缓存
Ext2/Ext3
Minix
FAT
VFS
虚拟文件系统
实际文件系统

Linux 是多年来发展起来一个新型操作系统，其最关键特征之一就是支持多个文件系统，使其愈加灵活，从而和很多其它操作系统共存。Linux支持ext，ext2，xia，minix，umsdos，msdes，fat32 ，ntfs,proc，stub，ncp，hpfs，affs 和 ufs 等多个文件系统。为了实现这一目标，Linux 对全部文件系统采取统一文件界面，用户经过文件操作界面来实现对不一样文件系统操作。VFS只是一个存在于内存中文件系统，在系统开启时产生，并随系统关闭而取消。
它关键功效包含：
（1）虚拟文件系统在整个文件系统最上层，为用户提供使用实际文件系统接口。即虚拟文件系统对用户来说是完全透明，用户并不知道使用是虚拟文件系统，甚至也不知道是哪个子文件系统在管理文件。用户只需发出通用命令操作即可。
（2）虚拟文件系统负责管理系统下各子文件系统多种缓冲区，尽最大可能为用户提供最好文件存取速率和确保文件完整性。
（3）包含到具体文件系统操作时，把它们映射到和控制文件、目录及inode相关物理文件系统。
（4）把设备和对应文件系统联络起来。
即使在linux中虚拟文件系统使用C语言来编写，不过虚拟文件系统使用是面向对象编程方法，将一个文件系统全部信息封装在一个结构体中。
为屏蔽实际文件系统差异，虚拟文件系统采取统一数据结构描述全部子文件系统，给用户提供标准文件操作数。未提供很好系统独立性，虚拟文件系统还提供标准文件操作数和实际子文件系统操作之间相互映射 。
1.2 实现VFS关键数据结构有：
· 超级块（superblock）对象: 存放系统中已安装文件系统相关信息。对于基于磁盘文件系统，这类对象通常对应于存放在磁盘上文件系统控制块,也就是说,每个文件系统全部有一个超级块对象.
· 索引节点（inode）对象: 存放相关具体文件通常信息。对于基于磁盘文件系统，这类对象通常对应于存放在磁盘上文件控制块(FCB),也就是说,每个文件全部有一个索引节点对象。每个索引节点对象全部有一个索引节点号,这个号唯一地标识某个文件系统中指定文件。
· 目录项（dentry）对象: 存放目录项和对应文件进行链接信息。VFS把每个目录看作一个由若干子目录和文件组成常规文件。比如，在查找 路径名/tmp/test时 , 内核为 根目录“/ ”创建一个目录项对象, 为根目录下 tmp项创建一个第二级目录项对象，为 /tmp 目录下test项创建一个第三级目录项对象。
· 文件(file)对象: 存放打开文件和进程之间进行交互相关信息。这类信息仅当进程访问文件期间存在于内存中。
1.2.1 超级块
很多具体文件系统中全部有超级块结构，超级块是这些文件系统中最关键数据结构，它是来描述整个文件系统信息，能够说是一个全局数据结构。Minix、Ext2等有超级块，VFS也有超级块，为了避免和后面介绍Ext2超级块发生混淆，这里用VFS超级块来表示。VFS超级块是多种具体文件系统在安装时建立，并在这些文件系统卸载时自动删除，可见，VFS超级块确实只存在于内存中，同时提到VFS超级块也应该说成是哪个具体文件系统VFS超级块。VFS超级块在inculde/fs/fs.h中定义，即数据结构super_block，该结构及其关键域含义以下：

struct super_block
{
/************描述具体文件系统整体信息域*****************
kdev_t s_dev; /* 包含该具体文件系统块设备标识符。
比如，对于 /dev/hda1，其设备标识符为 0x301*/
unsigned long s_blocksize; /*该具体文件系统中数据块大小，
以字节为单位 */
unsigned char s_blocksize_bits; /*块大小值占用位数，比如，
假如块大小为1024字节，则该值为10*/
unsigned long long s_maxbytes; /* 文件最大长度 */
unsigned long s_flags; /* 安装标志*/
unsigned long s_magic; /*魔数，即该具体文件系统区分于其它
文系统一个标志*/

/**************用于管理超级块域******************/
struct list_head s_list; /*指向超级块链表指针*/
struct semaphore s_lock /*锁标志位，若置该位，则其它进程
不能对该超级块操作*/
struct rw_semaphore s_umount /*对超级块读写时进行同时*/
unsigned char s_dirt; /*脏位，若置该位，表明该超级块已被修改*/
struct dentry *s_root; /*指向该具体文件系统安装目录目录项。*/
int s_count; /*对超级块使用计数*/
atomic_t s_active;
struct list_head s_dirty; /*已修改索引节点形成链表 */
struct list_head s_locked_inodes;/* 要进行同时索引节点形成链表*/
struct list_head s_files
/***********和具体文件系统相联络域*************************/
struct file_system_type *s_type; /*指向文件系统
file_system_type 数据结构指针 */
struct super_operations *s_op; /*指向某个特定具体文件系统用
于超级块操作函数集合 */
struct dquot_operations *dq_op; /* 指向某个特定具体文件系统
用于限额操作函数集合 */
u; /*一个共用体，其组员是多种文件系统
fsname_sb_info数据结构 */
};
1.2.2 VFS索引节点
文件系统处理文件所需要全部信息全部放在称为索引节点数据结构中。文件名能够随时更改，不过索引节点对文件是唯一，而且随文件存在而存在。相关使用索引节点原因将在下一章中深入介绍，这里关键是强调一点，具体文件系统索引节点是存放在磁盘上，是一个静态结构，要使用它，必需调入内存，填写VFS索引节点，所以，也称VFS索引节点是动态节点。这里用VFS索引节点来避免和下一章Ext2索引节点混淆。VFS索引节点数据结构inode在/includ/fs/fs.h中定义以下（2.4.x版本）：

　struct inode
{
/**********描述索引节点高速缓存管理域****************/
struct list_head i_hash; ／*指向哈希链表指针*/
struct list_head i_list; /*指向索引节点链表指针*/
struct list_head i_dentry;/*指向目录项链表指针*/

struct list_head i_dirty_buffers;
struct list_head i_dirty_data_buffers;
/**********描述文件信息域****************/
unsigned long i_ino; /*索引节点号*/
kdev_t i_dev; /*设备标识号 */
umode_t i_mode; /*文件类型和访问权限 */
nlink_t i_nlink; /*和该节点建立链接文件数 */
uid_t i_uid; /*文件拥有者标识号*/
gid_t i_gid; /*文件拥有者所在组标识号*/
kdev_t i_rdev; /*实际设备标识号*/
off_t i_size; /*文件大小（以字节为单位）*/
unsigned long i_blksize; /*块大小*/
unsigned long i_blocks; /*该文件所占块数*/
time_t i_atime; /*文件最终访问时间*/
time_t i_mtime; /*文件最终修改时间*/
time_t i_ctime; /*节点修改时间*/
unsigned long i_version; /*版本号*/
struct semaphore i_zombie; /*僵死索引节点信号量*/

/***********用于索引节点操作域*****************/
struct inode_operations *i_op; /*索引节点操作*/
struct super_block *i_sb; /*指向该文件系统超级块指针 */
atomic_t i_count; /*目前使用该节点进程数。计数为0，
表明该节点可丢弃或被重新使用 */
struct file_operations *i_fop; /*指向文件操作指针 */

unsigned char i_lock; /*该节点是否被锁定，用于同时操作中*/
struct semaphore i_sem; /*指向用于同时操作信号量结构*/
wait_queue_head_t *i_wait; /*指向索引节点等候队列指针*/
unsigned char i_dirt; /*表明该节点是否被修改过，若已被修改，
则 应该将该节点写回磁盘*/
struct file_lock *i_flock; /*指向文件加锁链表指针*/
struct dquot *i_dquot[MAXQUOTAS]; /*索引节点磁盘限额*/
/************用于分页机制域**********************************/
struct address_space *i_mapping; ／* 把全部可交换页面管理起来*/
struct address_space i_data;

/**********以下多个域应该是联合体****************************************/
struct list_head i_devices; /*设备文件形成链表*/
struct pipe_inode_info i_pipe; /*指向管道文件*/
struct block_device *i_bdev; /*指向块设备文件指针*/
struct char_device *i_cdev; /*指向字符设备文件指针*/

/*************************其它域***************************************/
unsigned long i_dnotify_mask; /* Directory notify events */
struct dnotify_struct *i_dnotify; /* for directory notifications */

unsigned long i_state; /*索引节点状态标志*/
unsigned int i_flags; /*文件系统安装标志*/
unsigned char i_sock; /*假如是套接字文件则为真*/
atomic_t i_writecount; /*写进程引用计数*/
unsigned int i_attr_flags; /*文件创建标志*/
__u32 i_generation /*为以后开发保留*/
/*************************各个具体文件系统索引节点********************/
union； /*类似于超级块一个共用体，其组员是多种具体文件系统fsname_inode_info数据结构 */
}

对inode数据结构深入说明
· 每个文件全部有一个inode,每个inode有一个索引节点号i_ino。在同一个文件系统中，每个索引节点号全部是唯一，内核有时依据索引节点号哈希值查找其inode结构。
· 每个文件全部有个文件主，其最初文件主是创建了这个文件用户，但以后能够改变。每个用户全部有一个用户组，且属于某个用户组，所以，inode结构中就有对应i_uid，i_gid，以指明文件主身份。
· inode 中有两个设备号，i_dev和i_rdev。首先，除特殊文件外，每个节点全部存放在某个设备上，这就是i_dev。其次，假如索引节点所代表并不是常规文件，而是某个设备，那就还得有个设备号，这就是i_rdev。
· 每当一个文件被访问时，系统全部要在这个文件inode中记下时间标识，这就是inode中和时间相关多个域。
· 每个索引节点全部会复制磁盘索引节点包含部分数据，比如文件占用磁盘块数。假如i_state域值等于I_DIRTY，该索引节点就是“脏”，也就是说，对应磁盘索引节点必需被更新。i_state域其它值有I_LOCK（这意味着该索引节点对象已加锁），I_FREEING（这意味着该索引节点对象正在被释放）。每个索引节点对象总是出现在下列循环双向链表某个链表中：
(1) 未用索引节点链表。变量inode_unusednext域 和prev域分别指向该链表中首元素和尾元素。这个链表用做内存高速缓存。
(2) 正在使用索引节点链表。变量inode_in_use指向该链表中首元素和尾元素。
(3) 脏索引节点链表。由对应超级块s_dirty域指向该链表中首元素和尾元素。
这三个链表全部是经过索引节点i_list域链接在一起。
· 属于“正在使用”或“脏”链表索引节点对象也同时存放在一个称为inode_hashtable链表中。哈希表加紧了对索引节点对象搜索，前提是系统内核要知道索引节点号及对应文件所在文件系统超级块对象地址。因为散列技术可能引发冲突，所以，索引节点对象设置一个i_hash域，其中包含向前和向后两个指针，分别指向散列到同一地址前一个索引节点和后一个索引节点；该域由此创建了由这些索引节点组成一个双向链表。

和索引节点关联方法也叫索引节点操作，由inode_operations结构来描述，该结构地址存放在i_op域中，该结构也包含一个指向文件操作方法指针（参见下一节“文件对象”）。
2.1.3目录项对象
每个文件除了有一个索引节点inode数据结构外，还有一个目录项dentry(directory enrty)数据结构。dentry 结构中有个d_inode指针指向对应inode结构。读者可能会问，既然inode结构和dentry结构全部是对文件各方面属性描述，那为何不把这两个结构“合而为一”呢？这是因为二者所描述目标不一样，dentry结构代表是逻辑意义上文件，所描述是文件逻辑上属性，所以，目录项对象在磁盘上并没有对应映像；而inode结构代表是物理意义上文件，统计是物理上属性，对于一个具体文件系统（如Ext2），Ext2_ inode结构在磁盘上就有对应映像。所以说，一个索引节点对象可能对应多个目录项对象。
dentry 定义在include/linux/dcache.h中：
struct dentry {
atomic_t d_count; /* 目录项引用计数器 */
unsigned int d_flags; /* 目录项标志 */
struct inode * d_inode; /* 和文件名关联索引节点 */
struct dentry * d_parent; /* 父目录目录项 */
struct list_head d_hash; /* 目录项形成哈希表 */
struct list_head d_lru; /*未使用 LRU 链表 */
struct list_head d_child; /*父目录子目录项所形成链表 */
struct list_head d_subdirs; /* 该目录项子目录所形成链表*/
struct list_head d_alias; /* 索引节点别名链表*/
int d_mounted; /* 目录项安装点 */
struct qstr d_name; /* 目录项名（可快速查找） */
unsigned long d_time; /* 由 d_revalidate函数使用 */
struct dentry_operations *d_op; /* 目录项函数集*/
struct super_block * d_sb; /* 目录项树根 （即文件超级块）*/
unsigned long d_vfs_flags;
void * d_fsdata; /* 具体文件系统数据 */
unsigned char d_iname[DNAME_INLINE_LEN]; /* 短文件名 */
};
下面对dentry结构给出深入解释。
一个有效dentry结构肯定有一个inode结构，这是因为一个目录项要么代表着一个文件，要么代表着一个目录，而目录实际上也是文件。所以，只要dentry结构是有效，则其指针d_inode肯定指向一个inode结构。可是，反过来则不然，一个inode却可能对应着不止一个dentry结构；也就是说，一个文件能够有不止一个文件名或路径名。这是因为一个已经建立文件能够被连接（link）到其它文件名。所以在inode结构中有一个队列i_dentry,通常代表着同一个文件全部目录项全部经过其dentry结构中d_alias域挂入对应inode结构中i_dentry队列。
在内核中有一个哈希表dentry_hashtable ，是一个list_head指针数组。一旦在内存中建立起一个目录节点dentry 结构，该dentry结构就经过其d_hash域链入哈希表中某个队列中。
内核中还有一个队列dentry_unused，通常已经没有用户（count域为0）使用dentry结构就经过其d_lru域挂入这个队列。
Dentry结构中除了d_alias 、d_hash、d_lru三个队列外，还有d_vfsmnt、d_child及d_subdir三个队列。其中d_vfsmnt仅在该dentry为一个安装点时才使用。另外，当该目录节点有父目录时，则其dentry结构就经过d_child挂入其父节点d_subdirs队列中，同时又经过指针d_parent指向其父目录dentry结构，而它自己各个子目录dentry结构则挂在其d_subdirs域指向队列中。
从上面叙述能够看出，一个文件系统中全部目录项结构或组织为一个哈希表，或组织为一颗树，或根据某种需要组织为一个链表，这将为文件访问和文件路径搜索奠定下良好基础。
2.1.4和进程相关文件结构
在具体介绍这多个结构以前，我们需要解释一下文件描述符、打开文件描述、系统打开文件表、用户打开文件表概念和它们联络。
1.文件对象
在Linux中，进程是经过文件描述符（file descriptors，简称fd）而不是文件名来访问文件，文件描述符实际上是一个整数。Linux中要求每个进程能最多能同时使用NR_OPEN个文件描述符，这个值在fs.h中定义，为1024*1024（2.0版中仅定义为256）。
每个文件全部有一个32位数字来表示下一个读写字节位置，这个数字叫做文件位置。每次打开一个文件，除非明确要求，不然文件位置全部被置为0，即文件开始处，以后读或写操作全部将从文件开始处实施，但你能够经过实施系统调用LSEEK（随机存放）对这个文件位置进行修改。Linux中专门用了一个数据结构file来保留打开文件文件位置，这个结构称为打开文件描述（open file description）。这个数据结构设置是煞费苦心，因为它和进程联络很紧密，能够说这是VFS中一个比较难于了解数据结构。
首先，为何不把文件位置干脆存放在索引节点中，而要多此一举，设一个新数据结构呢？我们知道，Linux中文件是能够共享，假如把文件位置存放在索引节点中，则假如有两个或更多个进程同时打开同一个文件时，它们将去访问同一个索引节点，于是一个进程LSEEK操作将影响到另一个进程读操作，这显然是不许可也是不可想象。
另一个想法是既然进程是经过文件描述符访问文件，为何不用一个和文件描述符数组相平行数组来保留每个打开文件文件位置？这个想法也是不能实现，原因就在于在生成一个新进程时，子进程要共享父进程全部信息，包含文件描述符数组。
我们知道，一个文件不仅能够被不一样进程分别打开，而且也能够被同一个进程前后数次打开。一个进程假如前后数次打开同一个文件，则每一次打开全部要分配一个新文件描述符，而且指向一个新file结构，尽管它们全部指向同一个索引节点，不过，假如一个子进程不和父进程共享同一个file结构，而是也如上面一样，分配一个新file结构，会出现什么情况了？让我们来看一个例子：
假设有一个输出重定位到某文件Ashell script（shell脚本），我们知道，shell是作为一个进程运行，当它生成第一个子进程时，将以0作为A文件位置开始输出，假设输出了2K数据，则现在文件位置为2K。然后，shell继续读取脚本，生成另一个子进程，它要共享shellfile结构，也就是共享文件位置，所以第二个进程文件位置是2K，将接着第一个进程输出内容后面输出。假如shell不和子进程共享文件位置，则第二个进程就有可能重写第一个进程输出了，这显然不是期望得到结果。
至此，已经能够看出设置file结构原因所在了。
file结构中关键保留了文件位置，另外，还把指向该文件索引节点指针也放在其中。file结构形成一个双链表，称为系统打开文件表，其最大长度是NR_FILE，在fs.h中定义为8192。
file结构在include\linux\fs.h中定义以下：
struct file
{
struct list_head f_list; /*全部打开文件形成一个链表*/
struct dentry *f_dentry; /*指向相关目录项指针*/
struct vfsmount *f_vfsmnt; /*指向VFS安装点指针*/
struct file_operations *f_op; /*指向文件操作表指针*/
mode_t f_mode; /*文件打开模式*/
loff_t f_pos; /*文件目前位置*/
unsigned short f_flags; /*打开文件时所指定标志*/
unsigned short f_count; /*使用该结构进程数*/
unsigned long f_reada, f_ramax, f_raend, f_ralen, f_rawin;
/*预读标志、要预读最多页面数、上次预读后文件指针、预读字节数和
预读页面数*/
int f_owner; /* 经过信号进行异步I/O数据传送*/
unsigned int f_uid, f_gid; /*用户UID和GID*/
int f_error; /*网络写操作错误码*/

unsigned long f_version; /*版本号*/
void *private_data; /* tty驱动程序所需 */

};
每个文件对象总是包含在下列一个双向循环链表之中：
· “未使用”文件对象链表。该链表既能够用做文件对象内存高速缓存，又能够看成超级用户备用存放器，也就是说，即使系统动态内存用完，也许可超级用户打开文件。因为这些对象是未使用，它们f_count域是NULL，该链表首元素地址存放在变量free_list中，内核必需确定该链表总是最少包含NR_RESERVED_FILES个对象，通常该值设为10。
· “正在使用”文件正确象链表：该链表中每个元素最少由一个进程使用，所以，各个元素f_count域不会为NULL，该链表中第一个元素地址存放在变量anon_list中。
假如VFS需要分配一个新文件对象，就调用函数get_empty_filp( )。该函数检测“未使用”文件对象链表元素个数是否多于NR_RESERVED_FILES，假如是，能够为新打开文件使用其中一个元素；假如没有，则退回到正常内存分配。
2．用户打开文件表
每个进程用一个files_struct结构来统计文件描述符使用情况，这个files_struct结构称为用户打开文件表，它是进程私有数据。files_struct结构在include/linux/sched.h中定义以下：
struct files_struct {
atomic_t count; /* 共享该表进程数 */
rwlock_t file_lock; /* 保护以下全部域,以免在
tsk->alloc_lock中嵌套*/
int max_fds; /*目前文件对象最大数*/
int max_fdset; /*目前文件描述符最大数*/
int next_fd; ／*已分配文件描述符加1*/
struct file ** fd; /* 指向文件对象指针数组指针 */
fd_set *close_on_exec; /*指向实施exec( )时需要关闭文件描述符*/
fd_set *open_fds; /*指向打开文件描述符指针*/
fd_set close_on_exec_init;/* 实施exec( )时需要关闭文件描述符初 值集合*/
fd_set open_fds_init; /*文件描述符初值集合*/
struct file * fd_array[32];/* 文件对象指针初始化数组*/
};

fd域指向文件对象指针数组。该数组长度存放在max_fds域中。通常，fd域指向files_struct结构fd_array域，该域包含32个文件对象指针。假如进程打开文件数目多于32，内核就分配一个新、更大文件指针数组，并将其地址存放在fd域中；内核同时也更新max_fds域值。

对于在fd数组中有入口地址每个文件来说，数组索引就是文件描述符（file descriptor）。通常，数组第一个元素（索引为0）是进程标准输入文件，数组第二个元素（索引为1）是进程标准输出文件，数组第三个元素（索引为2）是进程标准错误文件（参见图8.3）。请注意，借助于dup( )、dup2( )和 fcntl( ) 系统调用，两个文件描述符就能够指向同一个打开文件，也就是说，数组两个元素可能指向同一个文件对象。当用户使用shell结构（如2>&1）将标准错误文件重定向到标准输出文件上时，用户总能看到这一点。
open_fds域包含open_fds_init域地址，open_fds_init域表示目前已打开文件文件描述符位图。max_fdset域存放位图中位数。因为数据结构fd_set有1024位，通常不需要扩大位图大小。不过，假如确实必需话，内核仍能动态增加位图大小，这很类似文件对象数组情形。
当开始使用一个文件对象时调用内核提供fget( )函数。这个函数接收文件描述符fd作为参数，返回在current->files->fd[fd]中地址，即对应文件对象地址，假如没有任何文件和fd对应，则返回NULL。在第一个情况下，fget( )使文件对象引用计数器f_count值增1。
文件

文件

文件

fd
stdin 0
stdin 1
stdin 2
当内核完成对文件对象使用时，调用内核提供fput( ) 函数。该函数将文件对象地址作为参数，并递减文件对象引用计数器f_count值，另外，假如这个域变为NULL，该函数就调用文件操作“释放”方法（假如已定义），释