为什么要有GDT?我们首先考虑一下在Real Mode下的编程模型:
在Real Mode下,我们对一个内存地址的访问是通过Segment:Offset的方式来进行的,其中Segment是一个段的Base Address,一个Segment的最大长度是64 KB,这是16-bit系统所能表示的最大长度。而Offset则是相对于此Segment Base Address的偏移量。Base Address+Offset就是一个内存绝对地址。由此,我们可以看出,一个段具备两个因素:Base Address和Limit(段的最大长度),而对一个内存地址的访问,则是需要指出:使用哪个段?以及相对于这个段Base Address的Offset,这个Offset应该小于此段的Limit。当然对于16-bit系统,Limit不要指定,默认为最大长度64KB,而 16-bit的Offset也永远不可能大于此Limit。我们在实际编程的时候,使用16-bit段寄存器CS(Code Segment),DS(Data Segment),SS(Stack Segment)来指定Segment,CPU将段积存器中的数值向左偏移4-bit,放到20-bit的地址线上就成为20-bit的Base Address。
到了Protected Mode,内存的管理模式分为两种,段模式和页模式,其中页模式也是基于段模式的。也就是说,Protected Mode的内存管理模式事实上是:纯段模式和段页式。进一步说,段模式是必不可少的,而页模式则是可选的——如果使用页模式,则是段页式;否则这是纯段模式。
既然是这样,我们就先不去考虑页模式。对于段模式来讲,访问一个内存地址仍然使用Segment:Offset的方式,这是很自然的。由于 Protected Mode运行在32-bit系统上,那么Segment的两个因素:Base Address和Limit也都是32位的。IA-32允许将一个段的Base Address设为32-bit所能表示的任何值(Limit则可以被设为32-bit所能表示的,以2^12为倍数的任何指),而不象Real Mode下,一个段的Base Address只能是16的倍数(因为其低4-bit是通过左移运算得来的,只能为0,从而达到使用16-bit段寄存器表示20-bit Base Address的目的),而一个段的Limit只能为固定值64 KB。另外,Protected Mode,顾名思义,又为段模式提供了保护机制,也就说一个段的描述符需要规定对自身的访问权限(Access)。所以,在Protected Mode下,对一个段的描述则包括3方面因素:[Base Address, Limit, Access],它们加在一起被放在一个64-bit长的数据结构中,被称为段描述符。这种情况下,如果我们直接通过一个64-bit段描述符来引用一个段的时候,就必须使用一个64-bit长的段积存器装入这个段描述符。但Intel为了保持向后兼容,将段积存器仍然规定为16-bit(尽管每个段积存器事实上有一个64-bit长的不可见部分,但对于程序员来说,段积存器就是16-bit的),那么很明显,我们无法通过16-bit长度的段积存器来直接引用64-bit的段描述符。
怎么办?解决的方法就是把这些长度为64-bit的段描述符放入一个数组中,而将段寄存器中的值作为下标索引来间接引用(事实上,是将段寄存器中的高13 -bit的内容作为索引)。这个全局的数组就是GDT。事实上,在GDT中存放的不仅仅是段描述符,还有其它描述符,它们都是64-bit长,我们随后再讨论。
GDT可以被放在内存的任何位置,那么当程序员通过段寄存器来引用一个段描述符时,CPU必须知道GDT的入口,也就是基地址放在哪里,所以Intel的设计者门提供了一个寄存器GDTR用来存放GDT的入口地址,程序员将GDT设定在内存中某个位置之后,可以通过LGDT指令将GDT的入口地址装入此积存器,从此以后,CPU就根据此积存器中的内容作为GDT的入口来访问GDT了。
GDT是Protected Mode所必须的数据结构,也是唯一的——不应该,也不可能有多个。另外,正象它的名字(Global Descriptor Table)所揭示的,它是全局可见的,对任何一个任务而言都是这样。
EXT2FS第二代扩展文件系统(英语:second extended filesystem,缩写为 ext2),是LINUX内核所用的文件系统。它开始由Rémy Card设计,用以代替ext,于1993年1月加入linux核心支持之中。ext2 的经典实现为LINUX内核中的ext2fs文件系统驱动,最大可支持2TB的文件系统,至linux核心2.6版时,扩展到可支持32TB。其他的实现包括GNU Hurd,Mac OS X (第3方),Darwin (第3方),BSD。ext2为数个LINUX发行版的默认文件系统,如Debian、Red Hat Linux等 。
简介
其单一文件大小与文件系统本身的容量上限与文件系统本身的簇大小有关,在一般常见的 x86 电脑系统中,簇最大为 4KB, 则单一文件大小上限为 2048GB, 而文件系统的容量上限为 16384GB。
但由于目前核心 2.4 所能使用的单一分割区最大只有 2048GB,实际上能使用的文件系统容量最多也只有 2048GB。
至于Ext3文件系统,它属于一种日志文件系统,是对ext2系统的扩展。它兼容ext2,并且从ext2转换成ext3并不复杂。
Ext2文件系统具有以下一般特点:
1、当创建Ext2文件系统时,系统管理员可以根据预期的文件平均长度来选择最佳的块大小(从1024B——4096B)。例如,当文件的平均长度小于几千字节时,块的大小为1024B是最佳的,因为这会产生较少的内部碎片——也就是文件长度与存放块的磁盘分区有较少的不匹配。另一方面,大的块对于 大于几千字节的文件通常比较合合适,因为这样的磁盘传送较少,因而减轻了系统的开销 [1] 。
2、当创建Ext2文件系统时,系统管理员可以根据在给定大小的分区上预计存放的文件数来选择给该分区分配多少个索引节点。这可以有效地利用磁盘的空间。
3、文件系统把磁盘块分为组。每组包含存放在相邻磁道上的数据块和索引节点。正是这种结构,使得可以用较少的磁盘平均寻道时间对存放在一个单独块组中的文件并行访问。
4、在磁盘数据块被实际使用之前,文件系统就把这些块预分配给普通文件。因此当文件的大小增加时,因为物理上相邻的几个块已被保留,这就减少了文件的碎片。
5、支持快速符号链接。如果符号链接表示一个短路径名(小于或等于60个字符),就把它存放在索引节点中而不用通过由一个数据块进行转换。
Ext2还包含了一些使它既健壮又灵活的特点:
1、文件更新策略的谨慎实现将系统崩溃的影响减到最少。我们只举一个例子来体现这个优点:例如,当给文件创建一个硬链接时,首先增加磁盘索引节点中 的硬链接计数器,然后把这个新的名字加到合适的目录中。在这种方式下,如果在更新索引节点后而改变这个目录之前出现一个硬件故障,这样即使索引节点的计数 器产生错误,但目录是一致的。因此,尽管删除文件时无法自动收回文件的数据块,但并不导致灾难性的后果。如果这种处理的顺序相反(更新索引节点前改变目 录),同样的硬件故障将会导致危险的不一致,删除原始的硬链接就会从磁盘删除它的数据块,但新的目录项将指向一个不存在的索引节点。如果那个索引节点号以 后又被另外的文件所使用,那么向这个旧目录的写 *** 作将毁坏这个新的文件。
2、在启动时支持对文件系统的状态进行自动的一致性检查。这种检查是由外部程序e2fsck完成的,这个外部程序不仅可以在系统崩溃之后被激活,也 可以在一个预定义的文件系统安装数(每次安装 *** 作之后对计数器加1)之后被激活,或者在自从最近检查以来所花的预定义时间之后被激活。
3、支持不可变(immutable)的文件(不能修改、删除和更名)和仅追加(append-only)的文件(只能把数据追加在文件尾)。
4、既与Unix System V Release 4(SVR4)相兼容,也与新文件的用户组ID的BSD语义相兼容。在SVR4中,新文件采用创建它的进程的用户组ID;而在BSD中,新文件继承包含它 的目录的用户组ID。Ext2包含一个安装选项,由你指定采用哪种语义。
即使Ext2文件系统是如此成熟、稳定的程序,也还要考虑引入另外几个负面特性。目前,一些负面特性已新的文件系统或外部补丁避免了。另外一些还仅仅处于计划阶段,但在一些情况下,已经在Ext2的索引节点中为这些特性引入新的字段。最重要的一些特点如下:
块片(block fragmentation)
系统管理员对磁盘的访问通常选择较大的块,因为计算机应用程序常常处理大文件。因此,在大块上存放小文件就会浪费很多磁盘空间。这个问题可以通过把几个文件存放在同一块的不同片上来解决。
透明地处理压缩和加密文件
这些新的选项(创建一个文件时必须指定)将允许用户透明地在磁盘上存放压缩和(或)加密的文件版本。
逻辑删除
一个undelete选项将允许用户在必要时很容易恢复以前已删除的文件内容。
日志
日志避免文件系统在被突然卸载(例如,作为系统崩溃的后果)时对其自动进行的耗时检查。
实际上,这些特点没有一个正式地包含在Ext2文件系统中。有人可能说Ext2是这种成功的牺牲品;直到几年前,它仍然是大多数Linux发布公司采用的首选文件系统,每天有成千上万的用户在使用它,这些用户会对用其他文件系统来代替Ext2的任何企图产生质疑。
Ext2中缺少的最突出的功能就是日志,日志是高可用服务器必需的功能。为了平顺过渡,日志没有引入到Ext2文件系统;但是,我们在后面 “Ext3文件系统”中会讨论,完全与Ext2兼容的一种新文件系统已经创建,这种文件系统提供了日志。不真正需要日志的用户可以继续使用良好而老式的Ext2文件系统,而其他用户可能采用这种新的文件系统。现在发行的大部分系统采用Ext3作为标准的文件系统。
Linux支持多种不同类型的文件系统:网络文件系统NFS,磁盘文件系统Extfs,特殊文件系统proc、tmpfs等。
Ext2fs文件系统基本概念
Inode
Ext2fs中,每个文件都用如下图所示的inode结构来描述,用户空间 *** 作的对象是文件路径和名称,系统kernel把路径名称解析成inode,通过inode号来访问它代表的文件。
Mode:包含两个数据,文件类型(普通文件/目录/字符设备/块设备/符号链接/管道)和用户访问权限信息(0660)。
Owner info:文件属组信息。
Size:文件长度,单位是byte。
Timestamps:文件访问和修改的时间戳。
Links count:这个项在上图中没有体现,它记录了这个inode存在多少个链接,创建新文件时,其inode的links count应该为1,文件被删除后,这个inode的links count就变为0。
Data Blocks:指向真实的文件数据块,因为大文件可能会分配很多的block,直接在inode中保存所有的数据块指针将会比较困难,也会浪费掉很多空间,毕竟系统中大文件的数量是占少数的,所以设计了间接块指针(Indirect blocks)和二级块指针(Double blocks)来指向真实数据块。
实际上还应该包含了inode号。
目录
在Ext2fs中,目录被看做一种特殊文件,也用一个inode来描述,目录的data block中保存了目录下的所有内容,每条内容叫做一个entry,结构如下:
每条entry都保存了inode号、entry的长度、文件名长度、文件类型,并且都是4字节对齐。
特别地,每个目录下有两个特殊的子目录,'.'和'..',分别代表当前目录和上一级目录,这两个目录文件其实是硬链接。其中'..'有一个重要的作用:FS checker(可以把文件系统umount后手动执行e2fsck看看)在检查文件系统的时候,就会使用’..‘来检查目录是否可以追溯到挂载根目录,如果检查失败,目录便会被链接到挂载根目录下面的lost+found。
链接
为了方便系统内文件共享,Linux支持了两种基本的链接文件:硬链接和软链接(也叫符号链接)。
硬链接并不是一个独立的文件,不占用inode,只是在目录下创建了一条entry,其中inode号保存的是目标文件的inode号,访问硬链接时,文件系统通过inode将访问 *** 作重定向到目标文件,实现了文件共享,所以硬链接就是多个文件名直接指向同一个inode,用stat命令也能看到其inode号就是目标文件的inode号,它的特点:
不能跨文件系统。
目标文件必须先存在(inode存在且link count不为0)。
只能对普通文件创建硬链接,目录不行。
删除一个硬链接文件并不影响其他有相同 inode 号的文件。
软链接是一个独立的文件,拥有自己的inode,其数据块存放的是目标文件的名称,访问软链接时,kernel先访问软链接的内容,拿到目标文件名,并重新启动路径解析,获取到目标文件inode号再向文件系统发起访问。软链接的特点:
可以跨文件系统。
文件和目录都可以。
可对不存在的文件或目标创建软链接。
软链接有自己文件属性和权限。
创建软链接时,链接计数 i_nlink 不会增加;
删除软链接并不影响被指向的文件,但若被指向的原文件被删除,则相关软连接被称为死链接(即 dangling link,若被指向路径文件被重新创建,死链接可恢复为正常的软链接)。
软链接的目标文件也可以是软链接,其解析过程是递归的。
注意:软链接创建时目标文件的路径指向使用绝对路径比较好,使用相对路径创建的软链接被移动后该软链接文件将成为一个死链接,因为链接数据块中记录的也是相对路径指向。
下面这个图清晰描述了硬链接和软连接之间的区别:
Ext2fs基本结构
在创建文件系统的时候,Ext2fs将设备(磁盘或者分区)划分成1K、2K或者4K的block,然后通过Block group来管理,Ext2fs/Ext3fs/Ext4fs的结构差不多(Ext2fs主要是少了日志功能相关的内容),大致如下图所示:
Super Block
Super Block是文件系统最重要的数据,它从设备开始位置偏移1024字节的地方开始存储,占用1个block。如果block的大小是1KB,那么Super Block就存放在block-1。如果block的大小是4KB,那Super block就存放在block-0。
在Ext2fs的第一个版本(reverson0),每个Block Group都会存储一份Super Block的一份副本,因为对空间浪费比较严重,后来的版本就只在部分Block Group(0、1、3、5、7、9这几个group)中保留了Super Block的副本,在这几个Group,和Super Block一起备份的还有Group Descriptor。当然,如果没有这么多Group,副本数量自然更少,在后面的demo中也可以看出来。其中Group-0中的Super Block叫作Primary Super Block,文件系统被mount时,VFS读取的也正是这份。
Super Block里面的具体数据包括:
inode和block的总数,以及还有多少未分配。
每个Block Group有多少个inode和block。
文件系统唯一身份标识符(UUID),每个设备上的文件系统UUID都不一样。
...
GDT
Group Descriptor Table,GDT在文件系统中的layout紧跟Super block后面,是文件系统第二关键的数据,它主要用于存放所有Block Group的信息:
Ext2fs为GDT预留了一部分空间,用于文件系统扩容。
通过冗余提高了文件系统可靠性:在多个group中保存了关键数据的冗余副本,包括super block、GDT,当这些关键数据损坏的时候,很容易从这些冗余副本中恢复。
提升性能:分成group后,inode table和data block之间的”距离“变近了,在执行I/O时,可能会减少磁头寻址的时间。
注:实际上inode size,每个group中的block数等参数都可以在创建文件系统的时候指定,具体命令参数参考man page。
Ext2fs的性能优化
为了提升I/O性能,Ext2fs内核代码也做了很多设计,其中有两个关键的技术:
提前读:当必须读取一个块时,内核代码在几个连续的块上请求I/O。通过这种方式,它试图确保要读取的下一个块已经加载到缓冲区缓存中。提前读通常在文件的连续读取期间执行,Ext2fs将它们扩展到目录读取,可以是显式读取(readdir(2)调用),也可以是隐式读取(namei内核目录查找)。
预分配:在将数据写入文件时,Ext2fs在分配新块时预先分配最多8个相邻块。具体预分配多少个块取决于block size:block size = 1KB,每次预分配2个block;block size = 2KB,每次预分配4个block;block size = 4KB,每次预分配8个block。当然,对于用touch创建的空文件是不会预分配block的。即使在非常满的文件系统上,预分配命中率也只有75%左右。这种预分配在负载较大的情况下可以获得良好的写性能,同时它还允许将连续的块分配给文件,从而加快未来的顺序读取。
下面是Ext2fs、Ext3fs和Ext4fs的一个简单对比:
只有Ext2fs的Filesystem state是not clean,Ext3fs和Ext4fs都是clean,Ext2fs刚被以读写模式mount时,这个state被设置成not clean,umount或者以只读模式mount时,state被设置成clean,启动时文件系统根据这个状态来决定是否要执行检查。
Ext3fs/Ext4fs的Super block中多了关于日志功能的信息。
Ext4fs的每个group多了校验和(checksum)数据。
当PC启动时,Intel系列的CPU首先进入的是实模式,并开始执行位于地址0xFFFF0处的代码,也就是ROM-BIOS起始位置的代码。BIOS先进行一系列的系统自检,然后初始化位
于地址0的中断向量表。最后BIOS将启动盘的第一个扇区装入到0x7C00,并开始执行此处
的代码。这就是对内核初始化过程的一个最简单的描述。
最初,linux核心的最开始部分是用8086汇编语言编写的。当开始运行时,核心将自
己装入到绝对地址0x90000,再将其后的2k字节装入到地址0x90200处,最后将核心的其余
部分装入到0x10000。
当系统装入时,会显示Loading...信息。装入完成后,控制转向另一个实模式下的汇
编语言代码boot/Setup.S。Setup部分首先设置一些系统的硬件设备,然后将核心从
0x10000处移至0x1000处。这时系统转入保护模式,开始执行位于0x1000处的代码。
接下来是内核的解压缩。0x1000处的代码来自于文件Boot/head.S,它用来初始化寄
存器和调用decompress_kernel( )程序。decompress_kernel( )程序由Boot/inflate.c,
Boot/unzip.c和Boot../misc.c组成。解压缩后的数据被装入到了0x100000处,这也是
linux不能在内存小于2M的环境下运行的主要原因。
解压后的代码在0x1010000处开始执行,紧接着所有的32位的设置都将完成: IDT、
GDT和LDT将被装入,处理器初始化完毕,设置好内存页面,最终调用start_kernel过程。
这大概是整个内核中最为复杂的部分。
[系统开始运行]
linux kernel 最早的C代码从汇编标记startup_32开始执行
startup_32:
start_kernel
lock_kernel
trap_init
init_IRQ
sched_init
softirq_init
time_init
console_init
#ifdef CONFIG_MODULES
init_modules
#endif
kmem_cache_init
sti
calibrate_delay
mem_init
kmem_cache_sizes_init
pgtable_cache_init
fork_init
proc_caches_init
vfs_caches_init
buffer_init
page_cache_init
signals_init
#ifdef CONFIG_PROC_FS
proc_root_init
#endif
#if defined(CONFIG_SYSVIPC)
ipc_init
#endif
check_bugs
smp_init
rest_init
kernel_thread
unlock_kernel
cpu_idle
・startup_32 [arch/i386/kernel/head.S]
・start_kernel [init/main.c]
・lock_kernel [include/asm/smplock.h]
・trap_init [arch/i386/kernel/traps.c]
・init_IRQ [arch/i386/kernel/i8259.c]
・sched_init [kernel/sched.c]
・softirq_init [kernel/softirq.c]
・time_init [arch/i386/kernel/time.c]
・console_init [drivers/char/tty_io.c]
・init_modules [kernel/module.c]
・kmem_cache_init [mm/slab.c]
・sti [include/asm/system.h]
・calibrate_delay [init/main.c]
・mem_init [arch/i386/mm/init.c]
・kmem_cache_sizes_init [mm/slab.c]
・pgtable_cache_init [arch/i386/mm/init.c]
・fork_init [kernel/fork.c]
・proc_caches_init
・vfs_caches_init [fs/dcache.c]
・buffer_init [fs/buffer.c]
・page_cache_init [mm/filemap.c]
・signals_init [kernel/signal.c]
・proc_root_init [fs/proc/root.c]
・ipc_init [ipc/util.c]
・check_bugs [include/asm/bugs.h]
・smp_init [init/main.c]
・rest_init
・kernel_thread [arch/i386/kernel/process.c]
・unlock_kernel [include/asm/smplock.h]
・cpu_idle [arch/i386/kernel/process.c]
start_kernel( )程序用于初始化系统内核的各个部分,包括:
*设置内存边界,调用paging_init( )初始化内存页面。
*初始化陷阱,中断通道和调度。
*对命令行进行语法分析。
*初始化设备驱动程序和磁盘缓冲区。
*校对延迟循环。
最后的function'rest_init' 作了以下工作:
・开辟内核线程'init'
・调用unlock_kernel
・建立内核运行的cpu_idle环, 如果没有调度,就一直死循环
实际上start_kernel永远不能终止.它会无穷地循环执行cpu_idle.
最后,系统核心转向move_to_user_mode( ),以便创建初始化进程(init)。此后,进程0开始进入无限循环。
初始化进程开始执行/etc/init、/bin/init 或/sbin /init中的一个之后,系统内核就不再对程序进行直接控制了。之后系统内核的作用主要是给进程提供系统调用,以及提供异步中断事件的处理。多任务机制已经建立起来,并开始处理多个用户的登录和fork( )创建的进程。
[init]
init是第一个进程,或者说内核线程
init
lock_kernel
do_basic_setup
mtrr_init
sysctl_init
pci_init
sock_init
start_context_thread
do_init_calls
(*call())->kswapd_init
prepare_namespace
free_initmem
unlock_kernel
execve
[目录]
--------------------------------------------------------------------------------
启动步骤
系统引导:
涉及的文件
./arch/$ARCH/boot/bootsect.s
./arch/$ARCH/boot/setup.s
bootsect.S
这个程序是linux kernel的第一个程序,包括了linux自己的bootstrap程序,
但是在说明这个程序前,必须先说明一般IBM PC开机时的动作(此处的开机是指
"打开PC的电源"):
一般PC在电源一开时,是由内存中地址FFFF:0000开始执行(这个地址一定
在ROM BIOS中,ROM BIOS一般是在FEOOOh到FFFFFh中),而此处的内容则是一个
jump指令,jump到另一个位於ROM BIOS中的位置,开始执行一系列的动作,包
括了检查RAM,keyboard,显示器,软硬磁盘等等,这些动作是由系统测试代码
(system test code)来执行的,随着制作BIOS厂商的不同而会有些许差异,但都
是大同小异,读者可自行观察自家机器开机时,萤幕上所显示的检查讯息。
紧接着系统测试码之后,控制权会转移给ROM中的启动程序
(ROM bootstrap routine),这个程序会将磁盘上的第零轨第零扇区读入
内存中(这就是一般所谓的boot sector,如果你曾接触过电脑病
毒,就大概听过它的大名),至於被读到内存的哪里呢? --绝对
位置07C0:0000(即07C00h处),这是IBM系列PC的特性。而位在linux开机
磁盘的boot sector上的正是linux的bootsect程序,也就是说,bootsect是
第一个被读入内存中并执行的程序。现在,我们可以开始来
看看到底bootsect做了什么。
第一步
首先,bootsect将它"自己"从被ROM BIOS载入的绝对地址0x7C00处搬到
0x90000处,然后利用一个jmpi(jump indirectly)的指令,跳到新位置的
jmpi的下一行去执行,
第二步
接着,将其他segment registers包括DS,ES,SS都指向0x9000这个位置,
与CS看齐。另外将SP及DX指向一任意位移地址( offset ),这个地址等一下
会用来存放磁盘参数表(disk para- meter table )
第三步
接着利用BIOS中断服务int 13h的第0号功能,重置磁盘控制器,使得刚才
的设定发挥功能。
第四步
完成重置磁盘控制器之后,bootsect就从磁盘上读入紧邻着bootsect的setup
程序,也就是setup.S,此读入动作是利用BIOS中断服务int 13h的第2号功能。
setup的image将会读入至程序所指定的内存绝对地址0x90200处,也就是在内存
中紧邻着bootsect 所在的位置。待setup的image读入内存后,利用BIOS中断服
务int 13h的第8号功能读取目前磁盘的参数。
第五步
再来,就要读入真正linux的kernel了,也就是你可以在linux的根目录下看
到的"vmlinuz" 。在读入前,将会先呼叫BIOS中断服务int 10h 的第3号功能,
读取游标位置,之后再呼叫BIOS 中断服务int 10h的第13h号功能,在萤幕上输
出字串"Loading",这个字串在boot linux时都会首先被看到,相信大家应该觉
得很眼熟吧。
第六步
接下来做的事是检查root device,之后就仿照一开始的方法,利用indirect
jump 跳至刚刚已读入的setup部份
第七步
setup.S完成在实模式下版本检查,并将硬盘,鼠标,内存参数写入到 INITSEG
中,并负责进入保护模式。
第八步
*** 作系统的初始化。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)