linux文件系统工作原理索引节点和目录项中一切皆文件

linux文件系统工作原理索引节点和目录项
linux中一切皆文件,普通文件、目录、块设备、套接字、管道也要通过统一的文件系统来管理。
linux为每位文件都分配两个数据结构,索引节点和目录项,主要拿来记录文件的元信息和目录结构。
索引节点

linux文件系统工作原理索引节点和目录项

linux中一切皆文件,普通文件、目录、块设备、套接字、管道也要通过统一的文件系统来管理。

linux为每位文件都分配两个数据结构,索引节点和目录项,主要拿来记录文件的元信息和目录结构。

索引节点是每位文件的惟一标志,目录项维护的正是文件系统的树形结构,目录项和索引节点关系是多对一,可以简单理解为:一个文件可以有多某些名。

通过硬链接为文件创建的别称,会对应不同的目录项,这种目录项本质还是链接同一个文件,所以其索引节点相同。

c盘最小单位是磁道(512B),然而这样每次读写那么小,效率很低。所以文件系统又把连续的磁道组成了逻辑块,每次都以逻辑块为最小单元,来管理数据,每次以逻辑块为最小单元,来管理数据,常见逻辑块大小为4KB,由连续的8个磁道组成。

两个注意点:

linux 文件系统优化_优化文件系统的管理_优化文件系统NTFS的管理

虚拟文件系统

目录项、索引节点、逻辑块以及超级块构成linux文件系统四大要素。为了支持各类不同文件系统,linux在用户进程和文件系统中间,又引入了一个具象层,即虚拟文件系统VFS.

VFS定义了一组所有文件系统都支持的数据结构和标准插口。

文件系统I/O

I/O分类:缓冲与非缓冲I/O,直接与非直接I/O,阻塞与非阻塞I/O,同步与异步I/O。

优化文件系统NTFS的管理_优化文件系统的管理_linux 文件系统优化

空间不足,df查看c盘,发觉剩余空间有好多

虽然不仅文件数据,索引节点也占用c盘空间,使用如下命令:

df-i

当发觉inode不足,c盘空间充足,可能就是过多小文件造成的。删掉那些小文件,或则把它们联通到索引节点充足的其他c盘中,就可以解决这个问题。

内核使用Slab机制,管理目录项和索引节点的缓存。/proc/meminfo只给出了Slab的整体大小,具体到每一种Slab缓存,还要查看/proc/slabinfo。

优化文件系统的管理_优化文件系统NTFS的管理_linux 文件系统优化

储存系统I/O工作原理:

储存系统的I/O,一般是整个系统中最慢的一环。所以,Linux通过多种缓存机制来优化I/O效率。比方说,为了优化文件访问的性能,会使用页缓存、索引节点缓存、目录项缓存等多种缓存机制,以降低对上层块设备的直接调用。同样,为了优化块设备的访问效率,会使用缓冲区,来缓存块设备的数据。

c盘性能指标

使用率只考虑有没有I/O,而不考虑I/O的大小。换句话说,当使用率是100%的时侯,c盘仍然有可能接受新的I/O恳求

不能孤立地去比较某一指标,而要结合读写比列、I/O类型(随机还是连续)以及I/O的大小,综合来剖析;在数据库、大量小文件等这类随机读写比较多的场景中嵌入式linux,IOPS更能反映系统的整体性能;而在多媒体等次序读写较多的场景中,吞吐量才更能反映系统的整体性能

优化文件系统的管理_优化文件系统NTFS的管理_linux 文件系统优化

遇见这些“狂打日志”的场景时,你可以用iostat、strace、lsof等工具来定位狂打日志的进程,找出相应的日志文件,再通过应用程序的插口,调整日志级别来解决问题。假如应用程序不能动态调整日志级别,你可能还须要更改应用的配置,并重启应用让配置生效。

为何strace跟踪这个进程,却没有发觉任何write系统调用?

由于写文件是由子线程执行的,所有strace跟踪进程没有见到write系统调用,可以通过pstree查看进程的线程信息,再用strace跟踪;或则通过strace-fppid跟踪所有线程

慢查询剖析

top、iostat剖析了系统的CPU和c盘使用情况,发觉了c盘的I/O困局。接着,我们利用pidstat,发觉困局是mysqld造成的。紧接着,我们又通过strace、lsoflinux 文件系统优化,找出了mysqld正在读的文件。同时,按照文件的名子和路径,我们找出了mysqld正在操作的数据库和数据表。综合这种信息,我们判定,这是一个没有借助索引造成的慢查询问题。

优化文件系统的管理_优化文件系统NTFS的管理_linux 文件系统优化

停止dataservice后,IO问题也会消失,为何?

案例应用访问的数据表,基于MyISAM引擎,而MyISAM的一个特征,就是只在显存中缓存索引,并不缓存数据。所以,在查询句子未能使用索引时,就须要数据表从数据库文件读入显存,之后再进行处理。

dataservice会不停的释放文件缓存,致使mysql不会借助c盘缓存。

redis慢先用top、iostat剖析了系统的CPU、内存和c盘使用情况,不过却发觉,系统资源并没有出现困局。为了进一步剖析,就须要你对系统和应用程序的工作原理有一定的了解。例如,明天的案例中,尽管c盘I/O并没有出现困局,但从Redis的原理来说,查询缓存时不应当出现大量的c盘I/O写操作。沿着这个思路,我们继续利用pidstat、strace、lsof、nsenter等一系列的工具,找出了两个潜在问题,一个是Redis的不合理配置,另一个是Python应用对Redis的滥用I/O基准测试工具

fio(flexibleI/OTester)

I/O性能优化

应用的优化

用追加写取代随机写,降低轮询开支,推动I/O写的速率利用缓存I/Olinux 文件系统优化,充分借助系统缓存,增加实际I/O的次数应用程序内部建立自己的缓存,或则用Redis这类外部缓存系统。这样,一方面,能在应用程序内部,控制缓存的数据和生命周期;另一方面,也能减少其他应用程序使用缓存对自身的影响。C标准库提供的fopen、fread等库函数,就会借助标准库的缓存,降低c盘的操作。而你直接使用open、read等系统调用时,就只能借助操作系统提供的页缓存和缓冲区等,而没有库函数的缓存可用须要频繁读写同一块c盘空间时,可以用mmap取代read/write,降低显存的拷贝次数在须要同步写的场景中,尽量将写恳求合并,而不是让每位恳求都同步写入c盘,即可以用fsync()代替O_SYNC在多个应用程序共享相同c盘时linux内存管理,为了保证I/O不被某个应用完全占用,推荐你使用cgroups的I/O子系统,来限制进程/进程组的IOPS以及吞吐量在使用CFQ调度器时,可以用ionice来调整进程的I/O调度优先级,非常是提升核心应用的I/O优先级。ionice支持三个优先级类:Idle、Best-effort和Realtime。其中,Best-effort和Realtime还分别支持0-7的级别,数值越小,则表示优先级别越高。

以上就是linux文件系统工作原理索引节点和目录项中一切皆文件的详细内容,更多请关注叮当号网其它相关文章!

文章来自互联网,只做分享使用。发布者:张大嘴,转转请注明出处:https://www.dingdanghao.com/article/299378.html

(0)
上一篇 2024-04-03 10:05
下一篇 2024-04-03 10:30

相关推荐

联系我们

在线咨询: QQ交谈

邮件:442814395@qq.com

工作时间:周一至周五,9:30-18:30,节假日休息

关注微信公众号