关于ext4的FUD是否合理?还是在某些生产系统中使用安全?


14

我想知道ext4在我的服务器上是否可以安全使用。但是我已经听到太多有关该问题的FUD,我对此感到担忧。

我们的系统可能会丢失一些数据,这不会有什么大不了的。即使是一整天的数据也不会消除太多的毛病。而且我们的系统绝对可以从延迟写入中受益。

就是说,从备份中恢复完整的文件系统将需要几天的时间,这是无法接受的。

是否有关于该主题的经验或见解?

Answers:


12

老实说,我现在暂不将ext4用于生产。

如果您遇到文件系统的实际性能问题(还有我可以理解的情况,由于ext3,我们在应用程序中的性能受到限制),还有其他选择。根据您选择的发行版,您也许可以使用jfs,xfs或reiserfs。这三者通常都将以不同的方式胜过ext3,并且这三者都比ext4更具测试性和稳定性。

因此,我的建议将是多个部分。首先,请彻底调查以确保您在正确的位置进行优化。在不同的文件系统上测试您的应用程序,并确保性能提高到足以使文件系统更改有效。

另外,根据您的应用程序,添加更多的RAM可能会提高性能。默认情况下,Linux将使用未提交给应用程序的任何RAM作为磁盘缓存。有时,在磁盘活动频繁的盒子上,拥有几GB“未使用”的RAM可以显着提高性能。

最后,您对时间轴的要求是什么?如果ext3没有削减它,而我今天不得不用不同的文件系统构建一台机器,那么我可能会使用xfs或jfs。如果我能将其推迟6到8个月,我可能会等一下ext4的发展。


1
感谢您的同理心反馈。:)不,我不着急。已经添加了一些工作奇迹的RAM。此时,我只是关注所有潜在的性能瓶颈,并了解我的选择。我最大的担心是使用模式的筛选,或者新的应用程序要求可能会改变我的一切。“做好准备”或任何座右铭。在纸上,Ext4似乎是一个可行的选择。我讨厌打折,因为竞争的文件系统种子FUD。因此,我的问题。
斯图·汤普森

4

当然,Ubuntu 9.04(轻松活泼)仍在其内核2.6.28版本中解决ext4的错误。有些错误似乎仅出现在ubuntu内核中,而不是在主线中,但这表明,如果您具有非主线内核,则可能会遇到类似的麻烦。

此页面是有关ext4问题的搜索,可能值得浏览。当前的一个严重问题(2009年5月6日)是导致内核锁定的问题330824。与上期(现定)涉及的数据丢失。但是我还没有听说整个文件系统有任何丢失,如果发生的话,我认为这将是个大新闻。

因此,我想说黄金时间还没有完全准备好。如果您真的需要它,那么可能值得设置一个测试服务器来使用它。暂时我会坚持使用主线内核,并测量性能提升-如果这种提升是巨大的,并且压力测试没有显示任何问题,那么可能值得尝试一下...


现在正是我所追求的那种细节。谢谢,米什。
斯图·汤普森


1

除非您担心达到ext3的极限,否则我不会打扰。尽管ext4提供了许多改进,但其中大多数并不是针对常规用户的。

通常,最安全的选择是可以在可预见的将来满足您的需求的最成熟的技术。如果您不需要新奇的事物,那么您将无益地增加风险(但是很小)。


1
我担心达到极限。不是今天,不是明天,而是第二天。我只是怀疑那些没有根据的反对者。(例如:我的主要功能是Java编码,但是直到今天,人们还是告诉我Java已经死了,并且支持垃圾邮件,例如“它太慢了”(很长一段时间没有实现)和“它太旧了”。 (嗯?)基本上,我对所了解的风险感到满意,为此,我需要了解具体情况。天哪...希望对您有意义!
斯图·汤普森

0

就是说,从备份中恢复完整的文件系统将需要几天的时间,这是无法接受的。

然后坚持使用ext3,作为奖励,任何带有Fedora USB钥匙的插槽都可以挂载您的驱动器。


那么,是否存在我可能会丢失整个文件系统的风险?
斯图·汤普森

1
始终存在风险。运行ext3的人数与运行ext4的人数表明ext4接受的实际测试较少。
戴夫·切尼

没有支持信息,您在这里的最后一句话听起来像FUD。在我听到的对ext4的所有批评中,总音量损失不是其中之一。如果您知道此类事件,请告知我们。我正在寻找这种具体的批评。
Stu Thompson,2009年

不是FUD,只是实用。ext3多年来一直是发行版的标准,ext4仅在2.6.28 en.wikipedia.org/wiki/Ext4中合并。您是否使用1.0产品?
戴夫·切尼

1
我已经阅读了维基。有一些可靠的1.0s,有一些伪劣的7.0s。我听到了抱怨,但不想因恐惧而瘫痪。就像我们的回答一样,FUD模糊且模糊,实质上是“新==风险太大”。我正在寻找细节。细节!
斯图·汤普森

0

ext4仍然很新。保守的方法是使用ext3或具有已知可靠性特征的东西。在这点上,我建议仅将ext4用于可靠性不是很关键的系统,或者ext4的新功能大大超过数据丢失风险的系统。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.