[闲聊]奇怪，升级完内核检测硬盘……

smartliu · #1

刚刚升级了系统，其中包括升级到新版本的内核。升级完后要求重启。重启后我竟然停在了fsck上，显示如下：

代码：全选

Checking file systems...
fsck 1.4.0.2(12-Jul-2007)
/dev/sd3 has been mounted 28 times without being checked, check forced.

检查过程很慢，花了将近两分钟。检查完后系统正常启动。

这个分区的文件系统是ext3的，不是说加了日志功能的ext3文件系统做fsck超快吗，怎么这次检查100GB左右的分区那么长时间？

leeaman · #2

/dev/sd3 has been mounted 28 times without being checked, check forced.

不关升级内核的事!

xhy · #3

/dev/sd3 has been mounted 28 times without being checked, check forced.

每挂载28次会进行一次检测
跟升级内核没什么关系

100G 两分钟算快的
两分钟能读取的文件最多不过7G

超快是跟几个小时相比较而言

windwiny · #4

所以扔掉ext3,用reiserfs

smartliu · #5

xhy 写了：/dev/sd3 has been mounted 28 times without being checked, check forced.

每挂载28次会进行一次检测
跟升级内核没什么关系

100G 两分钟算快的
两分钟能读取的文件最多不过7G

超快是跟几个小时相比较而言

每挂载28次就强行检测一次，我第一次听过。是Ubuntu特有的选项吗？

ext3不是加上了日志了吗？根据Daniel Robbins在ibm-developwork上的关于文件系统的文章里说，有了日志，fsck只检测出了问题的/日志不完整的那部分（似乎是这样）。如果这样的话，应该不会把全部内容都扫描一遍啊……

xhy · #6

smartliu 写了：
xhy 写了：/dev/sd3 has been mounted 28 times without being checked, check forced.

每挂载28次会进行一次检测
跟升级内核没什么关系

100G 两分钟算快的
两分钟能读取的文件最多不过7G

超快是跟几个小时相比较而言
每挂载28次就强行检测一次，我第一次听过。是Ubuntu特有的选项吗？

ext3不是加上了日志了吗？根据Daniel Robbins在ibm-developwork上的关于文件系统的文章里说，有了日志，fsck只检测出了问题的/日志不完整的那部分（似乎是这样）。如果这样的话，应该不会把全部内容都扫描一遍啊……

是文件系统的特性不是ubuntu的特有

100G两分钟很快了如果dirty的数据很多搞你两天都是正常的

smartliu · #7

xhy 写了：
smartliu 写了：
xhy 写了：/dev/sd3 has been mounted 28 times without being checked, check forced.

每挂载28次会进行一次检测
跟升级内核没什么关系

100G 两分钟算快的
两分钟能读取的文件最多不过7G

超快是跟几个小时相比较而言
每挂载28次就强行检测一次，我第一次听过。是Ubuntu特有的选项吗？

ext3不是加上了日志了吗？根据Daniel Robbins在ibm-developwork上的关于文件系统的文章里说，有了日志，fsck只检测出了问题的/日志不完整的那部分（似乎是这样）。如果这样的话，应该不会把全部内容都扫描一遍啊……
是文件系统的特性不是ubuntu的特有

100G两分钟很快了如果dirty的数据很多搞你两天都是正常的

两天？那不是ext2时代的事情吗？ext3还没解决这个问题吗？

xhy · #8

smartliu 写了：
xhy 写了：
smartliu 写了：
xhy 写了：/dev/sd3 has been mounted 28 times without being checked, check forced.

每挂载28次会进行一次检测
跟升级内核没什么关系

100G 两分钟算快的
两分钟能读取的文件最多不过7G

超快是跟几个小时相比较而言
每挂载28次就强行检测一次，我第一次听过。是Ubuntu特有的选项吗？

ext3不是加上了日志了吗？根据Daniel Robbins在ibm-developwork上的关于文件系统的文章里说，有了日志，fsck只检测出了问题的/日志不完整的那部分（似乎是这样）。如果这样的话，应该不会把全部内容都扫描一遍啊……
是文件系统的特性不是ubuntu的特有

100G两分钟很快了如果dirty的数据很多搞你两天都是正常的
两天？那不是ext2时代的事情吗？ext3还没解决这个问题吗？

]

问题的规模摆在这里没有办法的
即使是reiserfs4也一样

smartliu · #9

xhy 写了：
smartliu 写了：
xhy 写了：
smartliu 写了：
xhy 写了：/dev/sd3 has been mounted 28 times without being checked, check forced.

每挂载28次会进行一次检测
跟升级内核没什么关系

100G 两分钟算快的
两分钟能读取的文件最多不过7G

超快是跟几个小时相比较而言
每挂载28次就强行检测一次，我第一次听过。是Ubuntu特有的选项吗？

ext3不是加上了日志了吗？根据Daniel Robbins在ibm-developwork上的关于文件系统的文章里说，有了日志，fsck只检测出了问题的/日志不完整的那部分（似乎是这样）。如果这样的话，应该不会把全部内容都扫描一遍啊……
是文件系统的特性不是ubuntu的特有

100G两分钟很快了如果dirty的数据很多搞你两天都是正常的
两天？那不是ext2时代的事情吗？ext3还没解决这个问题吗？
]

问题的规模摆在这里没有办法的
即使是reiserfs4也一样

http://www.ibm.com/developerworks/cn/li ... index.html里面Daniel Robbins说的：

那么，fsck 如何处理日志文件系统呢？实际上，通常它什么都不做。它只是忽略文件系统并允许它被装载。在快速地恢复文件系统到达一致性状态的背后，真正起作用的在于 Linux 文件系统驱动程序中。当文件系统被装载时，Linux 文件系统驱动程序查看文件系统是否完好。如果由于某些原因出了问题，那么就需要对元数据进行修复，但不是执行对元数据的彻底扫描（就像 fsck 那样），而是查看日志。由于日志中包含了按时间顺序排列的近期的元数据修改记录，它就简单地查看最近被修改的那部分元数据。因而，它能够在几秒钟时间内将文件系统恢复到一致性状态。并且与 fsck 所采用的传统方法不同，这个日志重放过程在大型的文件系统上并不需要花更多的时间。多亏了日志，[color=darkred]数百 G[/color] 的文件系统元数据几乎能在瞬间恢复到一致性的状态。

xhy · #10

ext3是在ext2的基础上增加了日志
检测的流程是这样的
1 恢复日志的一致性
2 分析superblock 如果没有进一步检测的必要那么退出
3 进一步检测的过程

确保日志的一致性只是fsck的一部分
实际上ext3的fsck是调用e2fsck完成的
如果superblock指示有进一步检测的必要
那么e2fsck还会做进一步的传统型的检测
极端情况下甚至会检测所有的文件块

mic · #11

貌似reiserfs比较快。

smartliu · #12

xhy 写了：ext3是在ext2的基础上增加了日志
检测的流程是这样的
1 恢复日志的一致性
2 分析superblock 如果没有进一步检测的必要那么退出
3 进一步检测的过程

确保日志的一致性只是fsck的一部分
实际上ext3的fsck是调用e2fsck完成的
如果superblock指示有进一步检测的必要
那么e2fsck还会做进一步的传统型的检测
极端情况下甚至会检测所有的文件块

日志不是只是用来记录数据的改动吗？似乎从文章里看的第一步是回复元数据的一直性，然后再扫描从日志上看的最后修改的那一部分。