[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: ktempfile
From:       "Jos Poortvliet" <jospoortvliet () gmail ! com>
Date:       2007-10-17 20:57:10
Message-ID: 5c77e14b0710171357q2bda4072v9949557387a114d4 () mail ! gmail ! com
[Download RAW message or body]

On 10/17/07, Lubos Lunak <l.lunak@suse.cz> wrote:
> On st 17. října 2007, Jos Poortvliet wrote:
> > On 10/17/07, Oswald Buddenhagen <ossi@kde.org> wrote:
> > > On Wed, Oct 17, 2007 at 06:52:55PM +0200, Lubos Lunak wrote:
> > > >  Thinking of this, how should this actually happen, in practice? Config
> > > > files are written first to a temporary file and this file gets renamed
> > > > to the original name, atomically replacing the old file. How exactly
> > > > should it happen that the original file gets destroyed but the new file
> > > > doesn't manage to replace it properly?
> > >
> > > the metadata is safe. but the contents of the new file might not be on
> > > disk yet. XFS is/was particularly susceptible to this type of data loss.
> > > so fdatasync() is indeed the solution.
> >
> > So a file gets written to temp, then its copied over the old file. Now
> > if a hang occurs, either the file is copied, or not copied, right?
>
>  No, it is not. I take that back. This is exactly what's written above: The
> rename() is a different thing from writting the file contents, the kernel
> probably even considers them completely unrelated - rename() is acting on
> filesystem metadata, not on either of the files.

So do we have dataloss on our hands, or not? If the rename() isn't
carried out, the old file still exists? And if it's in the journal but
not carried out, it gets done when replaying the journal after the
crash?

>  Still, this seems a bit too much for something that has happened to me
> perhaps like once this year (=power outage, not data loss). Maybe if we first
> linked the old file contents to some backup file, then they should be kept
> for possible restore if things go wrong (KConfig could even do this
> automatically somehow). There's the I/O scheduler still to possibly reorder
> things, but I guess I'd take the chance in exchange for not blocking on disk
> writes. Too bad my favourite kernel filesystem hacker is on vacation,
> somebody having their own handy :) ?

Pitty Hans is in jail :D

> --
> Lubos Lunak
> KDE developer
> --------------------------------------------------------------
> SUSE LINUX, s.r.o.   e-mail: l.lunak@suse.cz , l.lunak@kde.org
> Lihovarska 1060/12   tel: +420 284 028 972
> 190 00 Prague 9      fax: +420 284 028 951
> Czech Republic       http//www.suse.cz
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[prev in list] [next in list] [prev in thread] [next in thread]