MogileFS 是一个大型的分布式支持 HTTP 的数据存储的系统,当然不会有一个传统的 "fsck" 组件. 他设计了一种机制来并行的,在线的,异步的检查整个文件系统. The MogileFS fsck 默认,会检查和核对每个 FID 的存储:

• 这个 FID 复制的份数是 replication policy 所指定的份数 (没有过多的复制) ,例如:有 3 份复本在所有的主机上.
• 每个复制的 FID 存储在这些系统中,都是存在的并是正确的大小.
• 如果缺少的文件(路径上请求不到文件), 它会尝试找到任何设备上是否有这个 FID。
• 检查 devcount cache, 和一些其它的次要的记录.
• 请注意,它并不会做文件校验.

FSCK 是被设计成强行严格进行检查.你不能只检查特定的域,类或文件的前缀.然而,每个新的 MogileFS 的版本,都会对 fsck 代码进行小的改进,你可以检查最新的代码,看有什么补充和更新。

当运行 FSCK的时候

你不应该没事就运行 fsck .正常的情况下没有必要运行,只有当重大事件后才有必要来偶尔来运行一下.象软件错误,重要的升级,停电等,这些才有必要运行 fsck. 另外,如果你编辑一个类复制策略(添加或删除副本), 变更不会生效,直到运行 fsck 的时候. FSCK 可以修复旧版本中的 bug. 它也可以帮助恢复这种情况,有一段时间你没有足够的独立存储主机但又需要满足复制的需求.这时 FID 会存在多个硬盘上,只是没有充足地主机来复制.

运行 MogileFS 的 FSCK

fsck 是由 mogadm 这个程序控制着,所有的操作都是由这个来控制,你可以直接使用 fsck 的命令来查看.

第一次启动时的 fsck, 只需运行 'mogadm fsck start' .一会后,就应该开始运行了.运行 'mogadm fsck status' 查看状态和进度.

FSCK 选项

你就在开始 fsck 时加几个选项.如果你想对较新的文件运行 fsck, 你可以告诉它从哪个 FID 的数目开始,或告诉 fsck 仅检查复制策略中指定的磁盘上的文件的状态。

监测 FSCK 的运行

如果你喜欢看数字增长,fsck 的监测功能是您的最佳选择！

你可能定期运行 'mogadm fsck status' 的状态来监测的 fsck 进度.请注意,状态信息版本 2.30. 2.33 以后略有不同是改进过的输出.有一个点非常需要注意,一旦 fsck 的切换"Running: No", 这时 fsck 仍然会过滤后几分钟的 FIDS,直到内部队列都空掉. 您可以通过 'mogadm fsck printlog' 来检查 fsck 的结果,或通过 'mogadm fsck taillog' 观看输出的结果.

调整 FSCK

比较好的主意是查看 tracker 的日志 (通过 syslog 或者 telnet 到 track 中运行 watch),你可以见到一些超时的错误. 如果这个错太多,你的集群就太忙了.

FSCK Workers的数量

你可以非常容易和简单的调整并行的 fsck 的 workers 的数量.

你可以监测数据库,存储集群的负载来慢慢增加 fsck 的 workers 的数量.trackers 会慢慢的提高 fsck 队列 worker 每次从 fsck 队列中获取多少内容.因此它可能需要几分钟,他们才能加大.不过,如果你增加很多的 fsck 的 work 是不是能让 fsck 工作的更加快,可能需要调整一些其他设置.

FSCK 速度设置

FSCK 有一些队列数量管理的选项 , 默认设置相对较低,以避免添加太多负载. 如果你有 25+ 以上的 worker (和这时你的集群并没超负荷^-^!) 你也许需要调整这些以让它的运行速度更快.

internal_queue_limit 这个值是指 tracker  从 fsck 数据库队列中一次取出的 FID 的数量. 如果你使用 '!stats' 的命令连接在 tracker 上查看看, 你会见到象 work_queue_for_fsck 0 之类的这样的各种变量.如果你运行了很多个 fsck 的 worker , 但这个统计非常低或, 增加 internal_queue_limit 将会让它执行更快. 但不要设置的过高..大约几千可能是个合适的值. 这是一个缓慢的内部斜线的增加,所以要有耐心点调.您要调整这个值保持不断的提供给队列任务又不能太多.

queue_size_for_fsck 这是给在 tracker 数据库的队列中一次取多少 FID 发送给 worker .太高,这会浪费你更多的磁盘空间,但是,如果队列是时常为零, 增加二倍 or 三倍的值来帮助你从队列中提前取得需求的内容.

queue_rate_for_fsck 注入到循环的每一个队列中的 FID 的数量(every other second-ish),如果队列是在 limit 之下.设置过高的变量，可能会导致太多DB负载，但过低的trackers 不能从队列中提前获得. 可在一次队列可能完成的总的 FID 的数量高达 queue_size_for_fsck + queue_rate_for_fsck.

结果代码的解释

• NOPA: FID 没有可用的路径(URL).
• POVI: FID 和相应的复制策略不一致.这可能意味着太少或太多的文件副本.
• MISS: FID 的文件可能不存在,应该存在至少一个拷贝在相应的磁盘.
• BLEN: 找到的文件大小不正确.
• GONE: 试图找到任何可以使用的,正确的拷贝,但没有找到可用.如果您收到这些错误,你应该深入您的应用程序,来找出为什么它为什么不翼而飞.
• SRCH: FSCK 开始彻底的搜索丢失的文件.
• FOND: FSCK 已恢复了被认为丢失的 FID 的拷贝.
• REPL: 根据复制策略来修复并同步文件.
• BCNT: FID 的 'devcount' 的 cache 是错误的.

如果你安装了一个足够一个新的 MogileFS:: utils.您可以对 fsck 的日志所指出 FID 运行 mogfiledebug.这个工具会输出非常详细的有关这个 fid 的相关信息.能帮你查询有关的错误.如果有必要,可以给这个信息发到 IRC 中.

如下,运行这个的结果:

清理 FSCK 运行时生成的信息

fsck status 会包括所有违反复制策略的日志的总合. 所以如果你不清掉运行生成的日志,你下次运行时会见到比实际更多的日志.另外这个日志也是非常占用数据库的空间的非常的大.所以你看完日志后最好运行 reset 它来清掉日志.当然也可以给这些信息复制到文件中.

建议继续学习：

1. GFS, HDFS, Blob File System架构对比    (阅读：9444)
2. MooseFS知多少    (阅读：5049)
3. MogileFS 的介绍(MogileFS 系列1)    (阅读：4146)
4. 一线DBA总结：MySQL搭配XFS文件系统优势最大    (阅读：4167)
5. 文件系统的树形结构改善构思    (阅读：3122)
6. linux环境下使用GFS文件系统    (阅读：2811)
7. 在 MogileFS 中使用 Nginx    (阅读：2715)
8. MogileFS 的客户端和API(MogileFS 系列4)    (阅读：2519)
9. MogileFS 的安装(MogileFS 系列2)    (阅读：2499)
10. Linux下如何迁移VG及文件系统    (阅读：2471)