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

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

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

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

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

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

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

两个注意点：

虚拟文件系统

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

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

文件系统I/O

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

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

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

df-i

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

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

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

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

c盘性能指标

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

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

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

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

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

慢查询剖析

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

停止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文件系统工作原理索引节点和目录项中一切皆文件的详细内容。更多信息请关注PHP中文网其他相关文章！