ext4 文件系统的一些记录
2013-07-28 00:42
225 查看
https://www.kernel.org/doc/Documentation/filesystems/ext4.txt
ext4 权威说明
http://computer-forensics.sans.org/blog/2010/12/20/digital-forensics-understanding-ext4-part-1-extents#
对ext4的extent有解释,有实际查看;
http://blog.csdn.net/evilcode/article/details/7006925
ext4的nodealloc相关分析
http://us.generation-nt.com/answer/ext4-data-writeback-performs-worse-than-data-ordered-now-help-205753041.html
在一些特定的情况下,writeback性能还会差,有人怀疑是众多小块写,也可能是磁盘个数多,nr_request太大导致其他资源不足。
关于writeback vs order(http://stackoverflow.com/questions/12845319/ordered-mode-vs-writeback-mode)
If we don't go much in detail , then the answer to the query is yes (at least in filesystem like ext3).In both the modes only filesystem metadata is written into the journal. The difference between writeback mode and ordered mode is that in Ordered mode filesystem groups metadata and relative data blocks so that data blocks are written to disk before the metadata is logged while in ordered only metadata is logged (& data blocks are not written into disk at all).
ii. From the implementation perspective(in terms of ext3), in ordered mode an additional function journal_dirty_data( ) is invoked on every buffer of data in the page to insert the buffer in a proper list of the active transactions. The JBD layer ensures that all buffers in this list are written to disk before the metadata buffers of the transaction.After that generic_commit_write( ) function is invoked, which inserts the data buffers in the list of the dirty buffers of the owner inode. In writeback mode , no such function like journal_dirty_data( ) is invoked on data buffers and only generic_commit_write( ) is called.
关于barrier(http://baike.baidu.com/view/2220807.htm)
磁 盘上配有内部缓存,以便重新调整批量数据的写操作顺序,优化写入性能,因此文件系统必须在日志数据写入磁盘之后才能写 commit 记录,若 commit 记录写入在先,而日志有可能损坏,那么就会影响数据完整性。Ext4 默认启用 barrier,只有当 barrier 之前的数据全部写入磁盘,才能写 barrier 之后的数据。(可通过 "mount -o barrier=0" 命令禁用该特性。)
-o discard 利于SSD类TRIM功能,但是看官方文档貌似认为还需要更多测试,到2.6.37似乎是比较稳定了。https://patrick-nagel.net/blog/archives/337
不用discard因为在频繁删除小文件的时候,sync会比较长时间;在系统清闲的时候调用fstrim可能更好;不过看起来fstrim不像是多么稳妥的方式,企业环境下还是不要用为好,借助SSD自己的驱动来做就好了。
ext4 权威说明
http://computer-forensics.sans.org/blog/2010/12/20/digital-forensics-understanding-ext4-part-1-extents#
对ext4的extent有解释,有实际查看;
http://blog.csdn.net/evilcode/article/details/7006925
ext4的nodealloc相关分析
http://us.generation-nt.com/answer/ext4-data-writeback-performs-worse-than-data-ordered-now-help-205753041.html
在一些特定的情况下,writeback性能还会差,有人怀疑是众多小块写,也可能是磁盘个数多,nr_request太大导致其他资源不足。
关于writeback vs order(http://stackoverflow.com/questions/12845319/ordered-mode-vs-writeback-mode)
If we don't go much in detail , then the answer to the query is yes (at least in filesystem like ext3).In both the modes only filesystem metadata is written into the journal. The difference between writeback mode and ordered mode is that in Ordered mode filesystem groups metadata and relative data blocks so that data blocks are written to disk before the metadata is logged while in ordered only metadata is logged (& data blocks are not written into disk at all).
ii. From the implementation perspective(in terms of ext3), in ordered mode an additional function journal_dirty_data( ) is invoked on every buffer of data in the page to insert the buffer in a proper list of the active transactions. The JBD layer ensures that all buffers in this list are written to disk before the metadata buffers of the transaction.After that generic_commit_write( ) function is invoked, which inserts the data buffers in the list of the dirty buffers of the owner inode. In writeback mode , no such function like journal_dirty_data( ) is invoked on data buffers and only generic_commit_write( ) is called.
关于barrier(http://baike.baidu.com/view/2220807.htm)
磁 盘上配有内部缓存,以便重新调整批量数据的写操作顺序,优化写入性能,因此文件系统必须在日志数据写入磁盘之后才能写 commit 记录,若 commit 记录写入在先,而日志有可能损坏,那么就会影响数据完整性。Ext4 默认启用 barrier,只有当 barrier 之前的数据全部写入磁盘,才能写 barrier 之后的数据。(可通过 "mount -o barrier=0" 命令禁用该特性。)
-o discard 利于SSD类TRIM功能,但是看官方文档貌似认为还需要更多测试,到2.6.37似乎是比较稳定了。https://patrick-nagel.net/blog/archives/337
不用discard因为在频繁删除小文件的时候,sync会比较长时间;在系统清闲的时候调用fstrim可能更好;不过看起来fstrim不像是多么稳妥的方式,企业环境下还是不要用为好,借助SSD自己的驱动来做就好了。
相关文章推荐
- Ubuntu17.10上模块化编译ext4文件系统
- rtems 文件系统(14)-jffs2使用问题记录
- 在Win10系统下如何开启文件历史记录功能
- 16T以上容量的分区使用ext4文件系统的方法
- ext4文件系统新特性
- Linux 3.0 文件系统EXT4 与 Btrfs测试比较
- ext3,ext4,xfs和btrfs文件系统性能对比
- 单独编译一个ext4文件系统模块(缺图后续加上)
- EXT4文件系统之间接块的ext4_get_block()
- 通过调用rundll32.exe来打开一些系统特定文件
- Ubuntu文件系统的一些基本命令
- Ext4文件系统架构(一)
- Linux下对lvm逻辑卷分区大小的调整(针对xfs和ext4不同文件系统)
- 一例Ext4文件系统fsck后损坏的修复过程
- linux-3.12.6 移植yaffs2文件系统记录
- Ext4文件系统的特性
- fsck 修复ext3文件系统(用于linux系统时间不对,文件系统信息有错引起的die with exit status等的一些问题)
- Linux下对LVM逻辑卷分区大小的调整(针对xfs和ext4不同文件系统)
- 关于ext3,ext4,xfs和btrfs文件系统性能对比