文件系统-笔记

裸IO与直接IO的区别

裸IO 绕过了文件系统存数据， 直接IO只是绕过了缓冲使用文件系统（比同步写少了 O_SYNV的保护）。

写时复制与原子操作

写时复制的步骤是，写新块完成后，替换旧块到空闲列表中；

保证了文件系统的宕机时的文件完整性，把随机写改成了连续写从而改善了写的性能，这个是伴随文件系统日志产生的。

从逻辑IO到物理IO被放大的例子和原因

从逻辑IO到物理IO放大的原因:

1.元数据（增加额外IO）

2.文件系统记录尺寸： 向上对齐IO大小（增加了字节数）；或者被打散IO（增加了IO的数量）

3.卷管理器奇偶校验: 读改写的周期增加额外IO



原文中的1字节写的替换例子是个很不错的极端情况，没有预热的大文件直接替换指定字节，

对文件系统是个和大负担，这里的最后的9.10步骤应该是没有写操作都会有的额外的元数据更改；

3，4，5 是可以通过文件预热提前做的，6是一定会做的预期动作，

而7，8 则是可以异步完成的，当前没有close和同步写的要求。

fsync 对比O_SYNC的优势

fsync() 对比 O_SYNC的优势（3.1问题） ，

1.同步提交前支持异步写入的数据通过合并写来提高性能

2.还有其他的操作会提交之前的写入，例如文件句柄close()，或一个文件中有过多的未提交缓存。

PS: O_SYNC是文件打开时使用的标志，这个在打开文件时就决定了。






预读 与例子 






这个readahead 可以测试一下很有用啊



python 参考https://stackoverflow.com/questions/38433912/how-to-call-syscall-readahead-in-python

【next: try】



 



 
 import ctypes, os

    # load ourselves, we already have libc
    libc = ctypes.CDLL(None, use_errno=True)

    # XXX - YMMV, ctypes doesn't have c_off_t much less c_off64_t.
    # Assume it's c_longlong, but don't count on that.
    off64_t = ctypes.c_longlong

    def readahead(fobj, offset, count):
        fno = fobj if isinstance(fobj, int) else fobj.fileno()

        code = libc.readahead(
            ctypes.c_int(fno),
            off64_t(offset),
            ctypes.c_size_t(count)
        )
        if code != 0:
            errno = ctypes.get_errno()
            raise OSError(errno, os.strerror(errno))






文件系统延时和测量位置

文件系统延时的测量位置， 只要为如下几个，应用程序，系统调用接口，VFS， 直接在文件系统上，对应上文中的，

文件系统延时消耗在文件系统，内核磁盘I/O子系统（包含VFS和系统调用接口） 和等待磁盘设备

 

对用测量延时的几个参数的主要

对应缓存命中率大于99%的文件系统，单位时间平均值会被缓存命中率淹没，而高延时为离散点，要配合全分布和单操作的延时来查看，这个和测量过程中的其他值是一样的查找过程，但是后期不是忽略而是进一步研究。

非阻塞IO

这里的例子是web server的stat() 查看文件，确保了文件在缓存中没有修改。

这里的使用应该多是读取吧？！因为写操作的在文件系统默认就是非同步的，如果需要同步写要使用O_SYNC标准的，使用强制同步写的。原文中提到使用非阻塞IO的目的是对多线程程序节省了创建多余线程的成本，这个还真没有考虑过，这么精细的使用线程，感觉都想实时嵌入式的使用方式了。