当心: Ext4 可能造成数据丢失
正在使用 Ext4 文件系统的同学可得当心了。据某些用户反映,它可能会造成你的数据丢失。国外一位 Kubuntu Jaunty 的用户称,使用 Ext4 文件系统使他丢失了大量的数据,相关描述可参见位于 launchpad 上的 bug 报告。
无独有偶,国内的 albert748 也遇到了类似的问题。他描述道,X 无缘无故死掉,断电重启后,发现 Firefox 的配置丢了很多。与上面那位国外用户一样,albert748 也使用 2.6.28 内核和 Ext4 文件系统。
今天,H-Online 刊登了一篇文章 Ext4 data loss; explanations and workarounds,其中对此进行了解释,并包含 Ext4 开发者 Ted Ts'o 提供的解决方案,有兴趣的同学可去看看。
Read More:
我还是比较冷静的,呵呵,还没升到ext4
我把ext3盘挂载为ext4,也试过丢失文件
依旧ext2 + reiserfs
吓我阿,我前段时间为了这个文件系统重装了,还丢失了很多数据
我还是比较冲动的,呵呵,已经升到ext4
已经升级到ext4 没发现此问题 继续等更新
貌似原因归咎于应用程序开发人员在编写覆盖文件的操作时,没有遵循POSIX标准,而是把ext3的行为当标准了。 兼容ext3方式的新补丁需要2.6.30内核才会有,还是不升ext4算了。
我在zfs上也碰到过相似的情况,猜测是在带日志的文件系统上非正常关机,导致系统自己回滚到一个较早的时间了。 不知道这个猜得对不对,谁懂Journaling给讲讲。
@Tigerf: Ts'o 的那篇文章讲得比较清楚了,一般我们覆盖文件分如下几步: 1. 写数据到 foo.tmp 2. 关闭 foo.tmp 3. 重命名 foo.tmp 到 foo。 ext3 保证在第3步时 foo.tmp 已经写到磁盘; ext4 不保证这个, 他认为按照 posix 标准,你应当在 2-3 步中间增加一次 fsync。当然在 2.6.30 中会增加一个选项保证 rename, close 前数据已经被写入磁盘。
可以关闭delayalloc选项,虽然会损失一些写入性能,但相对安全些。不过最近的e2fsprogs和kernel 2.6.28.8似乎并没有出现断电后没有恢复的情况。
还好比较冷静。性能<安全
firefox丢失配置文件很正常啊 以前用ext3断电后也丢过,还有nautilus的
我的home是ext3的,只是/是ext4的,不要紧的吧!!
呵呵,我一直用reiserfs
已经丢失过文件,已换回ext3...
用 JFS 的觉得性能还可以。
用XFS的經過...
ext3续行中,看来还要再观望一阵子了。
/分区我用了ext4, /home分区我还是用的resierfs
要说强行断电造成文件丢失,哪个文件系统都可能把?我的jfs也有这样的情况,不过我没有当回事而已
以后用的时候小心点了,还好我整盘安装的 Fedora 10 ,而且装在笔记本上,不会因为断电丢失数据。放心啦
从ext3转成exy4后,删除文件时老是死机,搞得我都不敢删东西了,其它的没发现,
我的配置文件有些都不能保存,不知道是不是跟EXT4有关。
等debian 默认支持ext4 ,思考随系统升级
我在xfs下面也碰到过。。
额。。
用下来还是reiser3好用……
@LI Daobing: 见鬼的 ext4 和 posix 标准……
大家都说 close 即暗示写入……
btrfs文件系统
借机请教下,如何查看系统使用的是何种模式来着?日志模式?还是什么?
我还是喜欢reiserfs,一直都是这样,reiserfs4能出来就好了~渴望啊~~
目前看来还是ext3稳定
额……完了,我/home是ext4的
哈哈,我的/home是ext3,其他都是ext4,如果丢某些系统文件或者软件的文件,大不了重装系统,自己的东西还是安全的
ext3对于一般桌面用户已很够了,ext4吗????!?!?!还是再等等 服务器还是jfs
不是已经测试了很多时间了吗?怎么还会有这个问题?我已经在使用ext4了。
哦,看来现在不能冲动
ext4 + 2.6.28.11
完了……我已经冲动的升到ext4了……祈祷吧……
不过要是按POSIX标准,关闭文件前先调用fsync(),那EXT4的dellayalloc不就失去意义了吗?期待自带UPS电源的硬盘.....
我也是为了这个才ext4才重装了系统的呀 不过好像还没出现什么问题,观察中。。。
对了,我的 /home是ext4 opera的书签老无缘无故没有 会不会有关系呢
所以说激进要彻底一点,一早就用上29的内核了
我老婆的archlinux就出现这样的问题。我六个分区,挂掉了两个。还好没有往里面存重要的数据。
这个Issue的patch已经加入到ubuntu 2.6.28-10内核中了。 https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/317781/comments/173
所以ubuntu 9.04用户可以不用担心了。
没遇到过这个情况,我的内核已经换过了,到是遇到了楼上的那位所说的,删除文件时会死机的情况
ext4不是很稳定,换回ext3。
档案系统应该是先求可靠性,再来才是效能,怎么posix标准把"档案能否安全写入"的选择交给开发者,这真是太不可思议了,这违反了日志式档案系统的设计目的阿,而且不是每个应用开发人员在熟悉posix标准后才开始进行开发,这导致了更多的问题
若真要追究的话,罪魁祸首就是不遵守标准的ext3,它提供的额外防护掩盖了开发人员的疏失,让这些不标准的应用执行不会出错,结果转换成遵守标准的ext4,这些应用就爆炸了
这个案例很像IE自订非标准html语法,结果这些网页都与其他浏览器不相容
还好我还没有换,看这样我这个ext3再用上一两年再换吧。
@larz: 表,罪魁祸首就是所谓 POSIX 标准。
@华华: 为什么你这样认为呢?
非正常关机什么文件系统都没法保证数据的吧。所以最终还是要避免非正常关机的发生才是。目前还在ext3上,等4月份的9.04再升上去。以前吃了不少追新的苦,现在老实了。稳定是一切,数据安全是第一位的。
@Tigerf: ZFS上发生的频率高么?ZFS的多个特性都应该能有效防止数据丢失和损坏才对啊。
ZFS上发生频率确实是很高,不知道是不是配置有问题,系统非正常关闭和死机时,没有及时关闭的文件都被滚回较早时间前.实在是没敢用下去.
菜鸟弱问:将来如要解决此问题,只是升级EXT4模块就行还是必须重新格式化分区?
@caicai
要把内核打补丁,重新编译内核。 文件格式没有问题。
@caicai: 升级内核,或者打补丁,不需要重新分区
@tangrongjun: 你老婆IT人员么?一直觉得LT上archer一堆,原来还没算带家属的。看来可以把数字x2了。
纠正一下各位一个观念,Sun开发人员设计编写的ZFS跟ext4的原理完全不同,所以请不要混淆这两种文件系统。ZFS使用的copy on write技术,这样就防止了日志损坏导致文件系统corruption的风险。据我所知,ZFS在linux上只有一个userland的实现,各位如果是在linux上使用zfs的话,出现数据丢失的情况应该是非常正常的,因为linux的zfs实现是一个非常不成熟的实验品。我个人在solaris和FreeBSD上使用ZFS并未出现大量数据丢失的情况,如果在linux上如各位所说,恐怕只是代码实现上的能力问题了。EXT4出现的问题,我认为应该是类似的问题,在代码实现上还有很多严重的漏洞所以导致数据安全受到影响