Thu, 03 Nov 2005
XFS information leak
Today one of our servers crashed, and one user lost the file he has been editing. The file did not contain neither a new data nor an old data, just some random garbage (part of it even appeared to formerly belong to some shell script). This is quite dangerous from the security point of view, because it means that after the crash (like a power failure or a hard reset) the files which have been written to near the time of the crash may contain random data from previously-unused blocks.
I have even hacked up a small program that just creates or rewrites a set of files with some "known" contents. When you hard-reset the computer running this program on the XFS volume, after the reset some of the files contain "random" garbage.
The same problem would probably appear even on ext3 with data=writeback mode. But I don't know about anybody who runs ext3 in this mode. The data=ordered mode, which is the default, does not have this problem.
I should probably write an article about my long-term experience with various filesystems some day. It seems all articles which compare the filesystems just do some performance measurements on one particular hardware, which tells nothing about a SMP scalability, or a performance over the device which allows parallel operations (such as RAID or LVM). Or, like this case, about the behaviour in corner cases such as system crashes or bad blocks. I think it does not matter whether the filesystem is 5 or 10% slower - if your HW runs at 95% of the disk or CPU utilization, you are screwed anyway and you need to buy a better hardware - the next month you will be at 100% and you would need to buy it anyway. What does matter OTOH is, how reliable the filesystem is and how stable are the filesystem tools (resierfsck is obviously the bad one here).