[Top] [All Lists]

[Bug 202] XFS data corruption

To: xfs-master@xxxxxxxxxxx
Subject: [Bug 202] XFS data corruption
From: bugzilla-daemon@xxxxxxxxxxx
Date: Tue, 10 Dec 2002 16:12:10 -0800
Sender: linux-xfs-bounce@xxxxxxxxxxx

cattelan@xxxxxxxxxxx changed:

           What    |Removed                     |Added
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX

------- Additional Comments From cattelan@xxxxxxxxxxx  2002-12-10 16:12 -------
From FAQ

Note time to sync is a functions of bdflush sync times.

Q: Why do I see binary NULLS in some files after recovery when I unplugged the

If it hurts don't do that!

* NOTE: XFS 1.1 and kernels => 2.4.18 has the asynchronous delete path which
means that you will see a lot less of these problems. If you still have not
updated to the 1.1 release or later, now would be a good time!

Basically this is normal behavior. XFS journals metadata updates, not data
updates. After a crash you are supposed to get a consistent filesystem which
looks like the state sometime shortly before the crash, NOT what the in memory
image looked like the instant before the crash. Since XFS does not write data
out to disk immediately unless you tell it to with fsync or an O_SYNC open (the
same is true of other filesystems), you are looking at an inode which was
flushed out to disk, but for which the data was never flushed to disk. You will
find that the inode is not taking any disk space since all it has is a size,
there are no disk blocks allocated for it yet.

This same will apply to other metadata only journaling filesystems. The current
linux kernel VM will write out the metadata after 1/60th of a second and the
data after 30 seconds. So the possibility of losing data when unplugging the
power within 30 seconds is quite large. The only way of being sure that your
data will get to the disk is using fsync in the program of sync after closing
the program. 

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

<Prev in Thread] Current Thread [Next in Thread>