Re: kconfig's file handling (was: XFS: how to NOT null files on fsck?)

Re: kconfig's file handling (was: XFS: how to NOT null files on fsck?)

[Roy Butler]

On Tue, Jul 13, 2004 at 02:31:43PM +0200, Waldo Bastian wrote:
 >
 > 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

Re: kconfig's file handling (was: XFS: how to NOT null files on fsck?)

[Chris Wedgwood]

On Tue, Jul 13, 2004 at 11:27:50PM -0700, Roy Butler wrote:

> 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

[Roy Butler]

Chris,

Chris Wedgwood wrote:
> On Tue, Jul 13, 2004 at 11:27:50PM -0700, Roy Butler wrote:
> 
> 
>>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
> 

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