在小型文件系统上,这种检查仅仅是一种不便.但是,如果文件系统较大,则此检查可能需要数小时才能完成.当您的用户依赖此文件系统来提高工作效率时,假设它通过NFS服务于他们的主目录,您是否会禁用预定的文件系统检查?
我问这个问题,因为它现在是凌晨2点15分,我正在等待很长的fsck来完成(ext3)!
解决方法 180天的默认fsck时间是ext3不支持在线一致性检查的设计缺陷的解决方法.真正的解决方案是找到支持它的文件系统.我不知道是否有任何成熟的文件系统.这是一场真正的悲剧.也许btrfs会为我们节省一天.作为标准维护的一部分,我通过使用完整的fsck进行预定的重新启动来回应fsck意外多小时停机的问题.这比在生产时间遇到轻微腐败,并使其变为真正的中断更好.
问题的一个重要部分是ext3有一个不合理的缓慢fsck.尽管xfs具有更快的fsck,但它在分发时使用了太多内存来默认大型文件系统上的xfs.不过,在大多数系统中,这都不是问题.切换到xfs至少可以实现相当快的fsck.这可能使运行fsck作为正常维护的一部分更容易安排.
如果您正在运行RedHat并考虑使用xfs,那么您必须要注意它们阻止使用xfs的强烈程度以及可能很少有人在您正在运行的内核上使用xfs.
我的理解是ext4项目的目标是至少在某种程度上改善fsck的性能.
总结以上是内存溢出为你收集整理的linux – 180天后fsck或不fsck全部内容,希望文章能够帮你解决linux – 180天后fsck或不fsck所遇到的程序开发问题。
如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)