[转] 当心: Ext4 可能造成数据丢失

[RegentW]

当心: Ext4 可能造成数据丢失

2009-03-20 LinuxTOY (http://linuxtoy.org/archives/ext4-data-loss.html)

正在使用 Ext4 文件系统的同学可得当心了。据某些用户反映，它可能会造成你的数据丢失。国外一位 Kubuntu Jaunty 的用户称，使用 Ext4 文件系统使他丢失了大量的数据，相关描述可参见位于 launchpad 上的 bug 报告。

无独有偶，国内的 albert748 也遇到了类似的问题。他描述道，X 无缘无故死掉，断电重启后，发现 Firefox 的配置丢了很多。与上面那位国外用户一样，albert748 也使用 2.6.28 内核和 Ext4 文件系统。

今天，H-Online 刊登了一篇文章 Ext4 data loss; explanations and workarounds (http://www.h-online.com/open/Ext4-data- ... ews/112892)，其中对此进行了解释，并包含 Ext4 开发者 Ted Ts'o 提供的解决方案，有兴趣的同学可去看看。

[依窗吻风]

我昨天装的alpha6 就是用的Ext4，升级了所有更新之后 firefox一启动 系统就死掉，并且X经常无缘无故的死！难道我丢失文件了

[yiding_he]

我用 Ext4 到目前还没发生什么问题。

[bones7456]

概率也应该不高的,呵呵

[t3swing]

3月19日就得到Ted Ts'o 的证实,数据丢失主要是非法关机造成的,希望这个beta版出现卡死的概率低点,不然非法关机难免啊

[RegentW]

希望问题不严重 我电脑里的一级机密太多 丢失就全完了

[xieshaohu]

我现在都用poweroff -if来关机。
未出现过丢失数据的情况。

[mickeywaley]

汗，看的我都不敢升级了。
http://www.h-online.com/open/Ext4-data- ... ews/112892
Ext4 data loss; explanations and workarounds

Last week's announcement of possible data losses with Ext4 caused consternation and heated discussion. One user of an alpha version of Ubuntu 9.04 with Ext4 lost a large amount of data on a system crash immediately after starting KDE 4. Following a reboot, almost all the files written just before the crash showed a size of 0 bytes and were empty. He complained that nothing like that had ever happened to him with Ext3.

What had happened? When applications want to overwrite an existing file with new or changed data (for example, a configuration file after the user has changed a setting) frequently they first create a temporary file for the new data and then rename it with the system call - rename(). The logic behind this is that, if something goes wrong during the write process, say the computer crashes or there's a power failure, at least the old version of the file will be retained.

The process involves two things. First, metadata in the file system is changed. An inode is created for the new file that references the data, and a new index entry is generated that points to the new inode. After a rename(), the index entry of the old file is changed so that it points to the new inode. Second, the data itself is written. To do this, the filing system must first allocate a sufficient number of data blocks on the disk and then write the data to those blocks.

Both Ext3 and Ext4 first write all the changes to metadata in their journals, so even after the rename() nothing has actually been changed in the file system itself. If the power fails at this point, the new file doesn't yet exist in the filing system. The index entry of the old file points to the old inode and thus to the old data, and the changed metadata in the journal is not yet valid. A "commit" of the changes is required in the journal to make those changes valid. The file system only transfers the changed metadata to the file system some time after that (or on the next reboot after a crash).

But there's a crucial difference here between Ext3 and Ext4. Ext3 (with the standard mount option "data=ordered") only updates the metadata in the journal with that commit when the data of the new file has actually been written to the disk. This can take up to five seconds, during which time the data are still temporarily stored in the cache. This is meant to prevent old data turning up in a newly created file following a system crash. It is possible that the allocated data blocks were previously occupied by a file that had meanwhile been deleted and had not yet been overwritten with the new data. So, after a system crash, the file contains either the old or the new data, depending on whether the crash took place before or after the commit.

Ext4, on the other hand, has another mechanism: delayed block allocation. After a file has been closed, up to a minute may elapse before data blocks on the disk are actually allocated. Delayed block allocation allows the filing system to optimise its write processes, but at the price that the metadata of a newly created file will display a size of 0 bytes and occupy no data blocks until the delayed allocation takes place. If the system crashes during this time, the rename() operation may already be committed in the journal, even though the new file still contains no data. The result is that after a crash the file is empty: both the old and the new data have been lost.

Ext4 developer Ted Ts'o stresses in his answer to the bug report that Ext4 behaves precisely as demanded by the POSIX standard for file operations. Other file systems, such as XFS, display the same behaviour: the "safer" behaviour of Ext3 is only an unintended side effect. For Ts'o, the problem lies with application developers who take the forgiving behaviour of Ext3 to be a standard. He advises that, if an application wants to ensure that data have actually been written to disk, it must call the the function fsync() before closing the file.

Nevertheless, as a workaround, he very quickly wrote patches for Ext4 that recognise the rename() situation and ensure it behaves like Ext3, and a second procedure that uses ftruncate(). Now, however, he has provided a "proper" solution. The new ext4 mounting option "alloc_on_commit" gives Ext4 a mechanism analogous to "data=ordered" in Ext3, whereby metadata is not committed in the journal until after blocks have been allocated and the data has been written. However, this change probably won't arrive until version 2.6.30 of the kernel at the earliest.

[mickeywaley]

Ext4数据丢失;解释和解决方法

上周公布的数据造成损失Ext4惊愕和激烈的讨论。一个用户的alpha版的Ubuntu的9.04与Ext4丢失了大量的数据，系统崩溃后立即开始的KDE 4 。重新开机后，几乎所有的文件书面只是在飞机坠毁前成功显示大小为0字节，是空白。他抱怨说，没有过这样的事情给他，提供ext3 。

发生了什么事？申请时要覆写现有的文件与新的或更改的数据（例如，配置文件后，用户已改变了设置）经常他们首先创建一个临时文件进行了新的数据，然后将其重命名与系统调用-重命名（ ） 。此方式背后的逻辑是，如果出现问题在写的过程，说的计算机崩溃或有停电，至少有旧版本的文件将被保留。

这一过程涉及到两件事。首先，元数据的文件系统是改变。一个inode上创建新的文件，引用的数据，并进入一个新的指数产生指向新的inode 上。经过重新命名（ ），该指数进入旧文件被更改，以便它点到新的索引节点。第二，数据本身是书面。要做到这一点，备案系统首先必须分配足够数量的数据块在磁盘上，然后数据写入这些区块。

双方Ext3和Ext4首次写入所有变更数据的杂志，所以即使在重新命名（）没有什么实际上已改变了的文件系统本身。如果没有权力在这一点上，新的文件尚不存在的备案制度。索引项目的旧文件指出，旧的inode上，因此旧的数据，改变了数据在杂志尚未生效。一个“承诺”的修改是必要的杂志，使这些变化有效。档案系统唯一的改变数据传输的文件系统一段时间后，（或在下次重新启动崩溃后） 。

但有一个重要的差别，双方合作的Ext3和Ext4 。 Ext3 （标准挂载选项“数据=命令” ）只更新了元数据的杂志时，与该承诺的数据，新的文件实际上已写入磁盘。这可能需要长达5秒钟，在这期间的数据仍暂时存放在缓存中。这是为了防止旧数据转折点在一个新创建的文件后，系统崩溃。有可能是分配的数据块原先所占领的文件已被删除，同时尚未覆盖的新数据。因此，系统崩溃后，该文件包含要么旧的或新的数据，这取决于是否发生碰撞之前或之后的承诺。

Ext4 ，另一方面，有另一种机制：延迟块分配。后一个文件已经关闭，一分钟之前可能经过数据块磁盘上的实际分配。延迟块分配允许档案制度，以优化其写入进程，但在价格，该数据的新创建的文件将显示为0字节大小和占用的数据块，直到没有任何的延迟分配发生。如果系统崩溃在此期间，重新命名（）操作，可能已经在杂志上，尽管新的文件仍然不包含任何数据。其结果是，崩溃后的文件是空的：和旧的新的数据已经丢失。

Ext4开发特德Ts'o强调在回答错误报告认为Ext4行为正是所要求的POSIX标准的文件操作。其他文件系统，例如xfs ，显示相同的行为：在“安全”的行为Ext3只是一个意想不到的副作用。为Ts'o ，问题在于谁与应用开发商采取宽容行为Ext3是一个标准。他建议说，如果应用程序要确保数据实际上已经写入磁盘，它必须调用的函数fsync （ ），然后再关闭该文件。

然而，作为一种替代方法，他很快写补丁Ext4的承认重新命名（ ）的情况，并确保它的行为像Ext3 ，和第二个程序，使用ftruncate （ ） 。然而，现在他提供了一个“适当”的解决办法。新的ext4安装选项“ alloc_on_commit ”一个机制，使Ext4类似“数据=下令”在Ext3 ，即数据是不是在杂志上之后区块已分配和数据。然而，这种变化可能不会到达之前版本2.6.30的内核在最早

[kunkun0217]

用户文件不放在ext4上就可以了，只把ext4用在引导or系统盘上就能够提高开机速度。
一般使用察觉不到ext4会很快。

[RegentW]

9楼兄弟，少用这种所谓全文翻译啊，搞不好更害人的

[速腾1994]

重新开机后，几乎所有的文件书面只是在飞机坠毁前成功显示大小为0字节，是空白。
我ca！

[LFive]

。。。。。

[hubert_star]

我已经重现过这个错误无数次了，导致我非常重要的资料丢失，妈的

[wangdu2002]

我的Ext4好似很好使呀，没出过事！难道我人品不错？
────不过目前还没有非法关机。