Greg Freemyer wrote:
On Sun, Aug 15, 2010 at 8:30 AM, Matthias G. Eckermann <mge@novell.com> wrote:
On 2010-08-14 T 20:41 -0400 Greg Freemyer wrote:
On Sat, Aug 14, 2010 at 7:45 PM, Linda Walsh wrote:
Forward this from the linux-xfs list, in hoping that decision-makers will consider XFS as the default suse OS install choice. In the past (2.4.x kernel) XFS had significant data loss issues in the presence of unexpected shutdowns. I am afraid, this sounds a bit vague: please check, if in those cases the storage backends had been configured correctly: every journaling filesystem will suffer from data corruption, if there are any caches (such as disk write cache) inbetween the write and the disk.
It was very well known and accepted in the 2002-2005 timeframe that xfs on linux often would replace the content of files with nulls. ANd I mean exclusively nulls.
That is because that area of the file was RECORDED in the journal, as having been written to. The plug was pulled, before the data could be written. It's a violation of security policy and practice to NOT zero the data in such a case. XFS was also charted to handle a basic requirement of security, in that if a process has written to an object, the old data is guaranteed to be zeroed or reinitialized.
Thus many people that had the poor luck to use xfs for their home directory had the kde config files turned into null filled files due to a power outage.
---- That's because they overwrote them, then pulled the plug before the new data could be written. In my experience, it's very rare, but if someone has tweaked params to only have dirty data flushed to disk every 30-60 seconds, then they are asking for problems -- such was, and is still given as standard advice to save power. The problem with a journaled file system, is that the operations are recorded before the data is written, on the normal assumption that writing the list of what was done, 'operations', is faster than writing out all the data. Thus your file system maintains its integrity. If you write data before updating the disk, you end up with WRONG content -- which for a KDE text config, might not be so troublesome, but it's a binary file of almost any sort, having it NOT detected, could more easily be catastrophic. Having it zeroed makes it clear that information was in the process of being written to it. It didn't complete. Someone pulled the plug or the OS crashed. Not alot a fs can do about that. But the alternative is to have random garbage (which may look like reasonable text to a human eye, or may resync on an end-of-line if it is a text file), but would cause bad results if it was a program or binary financial information. Zeroing it the only safe thing to do. It may be inconvenient, but unplanned shutdowns many seconds of unflushed data in them is a bad situation no matter what. XFS didn't cause those files to be zeroed. Their programs wrote to those areas. That those areas no longer contained useful data was recorded in the journal. It's not until the data is flushed that the data in those files would be valid again. So really -- you may not like it, but zeroing it is the safest thing to do (besides being a security requirement). In other words -- other files systems leave those files in a corrupt and undefined state. Are you saying this is preferable? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org