分页： 1 / 1
[闲聊]奇怪，升级完内核检测硬盘……
发表于 ： 2007-10-11 10:06
由 smartliu
刚刚升级了系统，其中包括升级到新版本的内核。升级完后要求重启。重启后我竟然停在了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左右的分区那么长时间？
发表于 ： 2007-10-11 10:15
由 leeaman
/dev/sd3 has been mounted 28 times without being checked, check forced.
不关升级内核的事!
发表于 ： 2007-10-11 10:19
由 xhy
/dev/sd3 has been mounted 28 times without being checked, check forced.
每挂载28次会进行一次检测
跟升级内核没什么关系
100G 两分钟算快的
两分钟能读取的文件最多不过7G
超快是跟几个小时相比较而言
发表于 ： 2007-10-11 13:11
由 windwiny
所以扔掉ext3,用reiserfs
发表于 ： 2007-10-11 14:10
由 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只检测出了问题的/日志不完整的那部分（似乎是这样）。如果这样的话，应该不会把全部内容都扫描一遍啊……
发表于 ： 2007-10-11 14:32
由 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的数据很多 搞你两天都是正常的
发表于 ： 2007-10-11 14:44
由 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还没解决这个问题吗？
发表于 ： 2007-10-11 15:40
由 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也一样
发表于 ： 2007-10-11 15:59
由 smartliu
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] 的文件系统元数据几乎能在
瞬间恢复到一致性的状态。
发表于 ： 2007-10-11 18:05
由 xhy
ext3是在ext2的基础上增加了日志
检测的流程是这样的
1 恢复日志的一致性
2 分析superblock 如果没有进一步检测的必要 那么退出
3 进一步检测的过程
确保日志的一致性只是fsck的一部分
实际上ext3的fsck是调用e2fsck完成的
如果superblock指示有进一步检测的必要
那么e2fsck还会做进一步的传统型的检测
极端情况下甚至会检测所有的文件块
发表于 ： 2007-10-11 20:17
由 mic
貌似reiserfs比较快。
发表于 ： 2007-10-11 20:25
由 smartliu
xhy 写了：ext3是在ext2的基础上增加了日志
检测的流程是这样的
1 恢复日志的一致性
2 分析superblock 如果没有进一步检测的必要 那么退出
3 进一步检测的过程
确保日志的一致性只是fsck的一部分
实际上ext3的fsck是调用e2fsck完成的
如果superblock指示有进一步检测的必要
那么e2fsck还会做进一步的传统型的检测
极端情况下甚至会检测所有的文件块
日志不是只是用来记录数据的改动吗？似乎从文章里看的第一步是回复元数据的一直性，然后再扫描从日志上看的最后修改的那一部分。