kconfig's file handling (was: XFS: how to NOT null files on fsck?)
Quoted 6 lines · Waldo Bastian
The sentiment among filesystem developers seem to be that they don't care if they trash files as long as the filesystem itself remains in a consistent state. This kind of dataloss is the result of that attitude, either go complain with them if it bothers you, or use a filesystem that does it right.
Exactly. Don't blame KDE. Using XFS is equivalent to using non-battery-backed NVRAM on an external disk array. Great if performance is _the_ metric and lost results can easily be regenerated (like in frame rendering). By example, if you create a file, write to it, and then delete it fast enough, it will never hit the disk under XFS.
Roy Butler
Quoted 2 lines · Roy Butler
By example, if you create a file, write to it, and then delete it fast enough, it will never hit the disk under XFS.
Nor will it under some other filesystems... and in the above scenario I'm not sure that matters, why must a temporary file hit the disk at all?
--cw
Re: kconfig's file handling
Chris,
Quoted 7 lines · Chris Wedgwood
Quoted 2 lines · Roy Butler
By example, if you create a file, write to it, and then delete it fast enough, it will never hit the disk under XFS.
Quoted 7 lines
Nor will it under some other filesystems... and in the above scenario I'm not sure that matters, why must a temporary file hit the disk at all?
--cw
Suppose you want to do something with the file's contents before you delete it, but the system goes down before you have the chance. Wasn't that the impetus for this thread? With XFS, the potential for data loss is greater; that was my point. I believe that everyone who pays extra for batter-backed I/O caches would agree. :) Sure, different filesystems have their options, but this liability is ingrained in XFS.
Roy