首先快译通过
cat /proc/mounts
来查看当前挂载参数
options> - 定义了不同文件系统的特殊参数，不同文件系统的参数不尽相同。其中一些比较通用的参数有以下这些：
auto - 文件系统将在启动时，或被键入了 'mount -a' 的命令时自动被挂载。
noauto - 文件系统只在你的命令下被挂载。
exec - 允许执行此分区的二进制文件（默认值）。
noexec - 不允许此文件系统上的二进制文件被执行。
ro - 以只读模式挂载文件系统。
rw - 以读写模式挂载文件系统。
sync - I/O 同步进行。
async - I/O 异步进行。
flush - 指定 FAT 格式更加频繁地刷新数据，使得如复制对话框或是进度条持续到文件被写入到磁盘中。
user - 允许任意用户来挂载这一设备（同时有 noexec, nosuid, nodev 参数的属性）。
nouser - 只能被 root 挂载（默认值）。
defaults - 默认的挂载设置（即 rw, suid, dev, exec, auto, nouser, async）。
suid - 允许 suid 操作和设定 sgid 位。这一参数通常用于一些特殊任务，使一般用户运行程序时临时提升权限。
nosuid - 禁止 suid 操作和 sgid 位。
noatime - 不要更新文件系统上 inode access 记录，可以提升性能(参见 atime_options)。
nodiratime - 不要更新文件系统上 directory access inode 的记录，可以提升性能(参见 atime_options)。
relatime - 实时更新 inode access 记录。只有在记录中的访问时间早于当前访问才会被更新。（与 noatime 相似，但不会打断如 mutt 或其它程序探测文件在上次访问后是否被修改的进程。），可以提升性能(参见 atime_options)。
网上很多资料都提到要同时设置 noatime 和 nodiratime，不知道这个结论来自哪里，其实不需要像设置 noatime 那样设置 nodiratime，最可靠的资料应该是源代码，VPSee 查了一下源代码，发现在内核源代码 linux-2.6.33/fs/inode.c 文件里有一个 touch_atime 函数，可以看出如果 inode 的标记位是 NOATIME 的话就直接返回了，根本就走不到 NODIRATIME 那里去，所以只设置 noatime 就可以了，不必再设置 nodiratime.
Ext3 提供三种数据日志记录方式：data=writeback 、 data=ordered (默认) data=journal。
1 data=writeback 方式
data=writeback方式下，ext3根本不执行任何形式的数据日志记录，提供给您的是和在XFS，JFS和 ReiserFS文件系统中找到的类似的日志记录（仅元数据）。这会让最近修改的文件在出现意外的重新引导事件中被毁坏。如果不考虑这个缺点， data=writeback 方式在大多数情况下应该能够提供最佳的ext3性能。
2 data=ordered 方式
data=ordered方式下，ext3只是正式记录元数据，而在逻辑上将元数据和数据块分组到称为事务的单个单元中。到了将新的元数据写到磁盘上的时候， 首先写的是相关的数据块。
data=ordered方式有效地解决了在 data=writeback 方式下和大多数其它日志记录文件系统中发现的毁坏问题，而这是在不需要完整数据日志记录的情况下做到的。一般说来，data=ordered ext3文件系统执行的速度比data=writeback文件系统执行的速度稍微慢一些，但比对应的完整数据日志记录还是要快出许多。
将数据附加到文件时，data=ordered方式提供了ext3完整数据日志记录方式提供的所有完整性保证。
不过，如果正在覆盖某一部分文件，而此时系统崩溃，那么有可能所写的区将包含原始块和在其中散布了更新块的组合。这是因为 data=ordered 不提供首先覆盖哪一个数据块的保证，因此不能假设只是因为更新了被覆盖的块 x，也就更新了被覆盖的块 x-1。
data=ordered让写操作顺序由硬盘的写高速缓存决定。这个限制并不经常具有负面影响，因为附加的文件一般比覆盖的文件更普遍。出于这个原因，data=ordered 方式是对完整数据日志记录的一个很好的更高性能的替代。
3 data=journal 方式
data=journal 方式提供了完整数据和元数据日志记录。所有新数据首先写入日志，然后再写入它的最终位置。在崩溃情况下，可以重放日志，使数据和元数据处于一致的状态。
要指定日志方式，可以使用如下方式：
1 向/etc/fstab的选项节添加适当的字符串例如 data=journal
2 在调用 mount 时直接指定 -o data=journal 命令行选项。
如果您愿意指定用于根文件系统的数据日志记录方法data=ordered是缺省值，则可以使用名为 rootflags 的特殊内核引导选项。因此，要将根文件系统置于完整数据日志记录方式下，则向内核引导选项添加rootflags=data=journal
这里提到
数据库 （Postgres Data）：数据库应该放独立的RAID10上。 如果RAID是带电池的，mount 的时候给 data=writeback的选项
ext3 惊奇的journal 方式
读取 16Mb 的文件
结果让人惊奇。 data=journal 方式允许 16 兆文件以比其它 ext3 方式、ReiserFS，甚至 ext2（没有日志记录开销）高出 9 到 13 倍的速度读取：
写入文件系统 16 兆读取时间（秒）
ext2 78
ReiserFS 67
ext3 data=ordered 93
ext3 data=writeback 74
ext3 data=journal 7
Andrew 重复这个测试，但尝试从测试文件系统（而不是从其它文件系统）读取 16Mb 的文件，获得的结果是相同的。 那么，这意味着什么呢？不知什么原因，ext3 的 data=journal 方式非常适合于需要同时从磁盘读写数据的情况。 因此，ext3 的 data=journal 方式（被认为在几乎所有情况中是所有 ext3 方式中最慢的）实际上证明在需要最大化交互式 IO 性能的繁忙环境中具有重要的性能优势。可能 data=journal 方式毕竟没那么缓慢！
Andrew 仍然在尝试发现究竟为什么 data=journal 方式比其它方式好这么多。在这样做的同时，他也许能够对 ext3 的另外两种方式做必要调整，以便也能看到 data=writeback 和 data=ordered 方式的好处。
对 data=journal 的调整
有些人在繁忙的服务器上 ― 特别是在繁忙的 NFS 服务器上 ― 使用 ext3 的 data=journal 方式时曾经碰到一个特殊的性能问题。每隔 30 秒，服务器就会遇到磁盘写活动高峰，导致系统几乎陷于停顿。如果您遇到这个问题，修复它很容易。只要以 root 用户输入以下命令，就可以调整 Linux“脏”缓冲区刷新算法：
调整 bdflush echo 40 0 0 0 60 300 60 0 0 > /proc/sys/vm/bdflush
这些新的 bdflush 设置将导致 kupdate 每隔 0.6 秒而不是每隔 5 秒运行。另外，它们告诉内核每隔 3 秒而不是 30 秒（缺省值）刷新“脏”缓冲区。通过更有规律地将最近修改的数据刷新到磁盘，可以避免这些写操作的高峰。以这种方式执行的效率比较低，因为内核不太有机会组合写操作。但对于繁忙的服务器，写操作将更一致地进行，并将极大地改进交互式性能。
http://hi.baidu.com/aokikyon/blog/item/4d9d8fa1ad06ec91471064ab.html
结论是在嵌入式系统上
ext4的数据allocation竟然要等1分钟以上，这显然无法满足嵌入式的要求
解决方案是打开nodelalloc选项，尝试之，确有效！
从图上可以看出，对于很大的文件，16M的文件，几乎所有的情况都是delolloc的性能要好。 但是对于64K-512K的文件， 性能就要差很多。
对于文件unit的大小，可以看得出来256K是一个分水岭。 在接近256K的时候，延迟分配性能就要好很多，这个原因是因为我们的L2缓存是256K， 所以当写的数据接近256K的时候，由于延迟分配技术不用去分配Block 块，所以大部分的memory write都可以用来作为文件写page cache，如果有了分配block这些数据，就会导致cache不对其，所以性能就会比延迟分配差很多。
http://adaishu.blog.163.com/blog/static/175831286201151621721756/
alc,noalc
http://hi.baidu.com/leejun_2005/blog/item/e9de5408e5bea3d53ac7631b.html
在生产服务器上的/data分区用了noatime,nobarrier,data=writeback
看看效果
因为压力还不大所以暂时没用
echo "deadline" > /sys/block/sda/queue/scheduler
当然也可以在内核启动参数后面增加elevator=deadline
待续带编辑
阅读(6170) | 评论(0) | 转发(0) |
