进入此门的肯定都对journal block device有一定了解,需要对ext3文件系统有了解,多余的就不赘述。
为什么要设计JBD?
普通数据是存在硬盘上的,文件系统也是作为普通数据存在硬盘上,类似如果碰到突然断电的情况,硬盘就可能损坏,硬件损坏,还是要硬件设计保证,软件设计(JBD)就是解决软件错误,断电可能会导致软件...
DirectIO是write函数的一个选项,用来确定数据内容直接写到磁盘上,而非缓存中,保证即是系统异常了,也能保证紧要数据写到磁盘上,具体写文件的机制流程可以参考前面写的<Linux内核写文件流程>,DirectIO流程也是接续着写文件流程而来的。
内核走到__generic_file_aio_write函数时,系统根据file->f_flags &am...
ext2在设计之初的时候就是通过链表的方式管理目录下的文件项目,ext3,ext4也是直接继承过来了,但随着单个目录下管理的文件越来越多到几十万个,线性的链表查找文件,创建文件(先要查找同名文件)越来越慢,时间复杂的达到了O(n)的级别,尤其对于当前云存储大数据等概念,读写速度是不能接受的。
为了能快速查找,...
接上篇Linux内核读文件流程,写这篇Linux内核写文件流程。文中涉及的内核代码版本是linux内核版本号:3.0.13-0.27 sles11sp2版本。
用户态write函数到内核态的调用是:
SYSCALL_DEFINE3(write, unsigned int, fd, const char __user *, buf, size_t, count)
SYSCALL_DEFINE3调用的vfs_write,vfs_write调用rw_verify_...
主要描述从用户态启动文件读开始,直到磁盘驱动,linux内核代码所走过的流程。阅读者需要对linux内核的内存管理、ext系列的文件系统,块设备,页高速缓存等有一定了解,不了解也没关系,顺着代码读可能会吃力点而已,鉴于不可能将代码全贴出来,中间缺失的部分,请大家自行脑补吧。至于写文章的原因,作为一名高效的客服...
目前内核对ext4文件系统错误处理机制分为三种:1.不处理;2.内核panic;3.错误分区remount成只读形式。
处理机制的设定是在两个地方处理的,一个是在文件系统物理分区上设置,通过设置ext4文件系统分区的超级块中的“Errors behavior”参数,可以配置错误处理方式,一般默认处理方式是Continue(不处理),具体配置通过tu...
之前做技术研究的时候搞文件系统元数据镜像时处理过orphan inode的问题,而现在恰好有同事在做lsof时发现了一些的特殊的文件,lsof可以看到进程在使用,同时ls具体文件时却又看不到:
suse:~ # lsof /var | grep deleted
nscd 2831 root 8u REG 8,5 217016 42883 /var/run/nscd/db4Dqbpq (deleted)
nscd 2831 root 9r RE...