On st 17. října 2007, Jos Poortvliet wrote: > On 10/17/07, Oswald Buddenhagen 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. 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 :) ? -- 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 <<