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

List:       kde-devel
Subject:    Re: ktempfile
From:       Lubos Lunak <l.lunak () suse ! cz>
Date:       2007-11-08 16:26:41
Message-ID: 200711081726.41850.l.lunak () suse ! cz
[Download RAW message or body]

On Thursday 08 of November 2007, David Faure wrote:
> On Thursday 18 October 2007, Jaison Lee wrote:
> > [...]
>
> I think that what people missed in this thread is that history is shared
> among konqueror windows, which could be in different processes. So we do
> need to write to the file immediately so that your url comboboxes all have
> the new url in it (this isn't about statistics, it's about the url combo's
> items). Well, more precisely: the new url is sent to other windows using
> dcop/dbus, but if you open a new window (in a new process) it will read
> from the kconfig file. So a 5 minutes autosave would just lead to bugs.

 No, it wouldn't. If you open a file, write to it and close it, then the data 
is written somewhere, at least to the kernel buffers. When another process 
opens the file and reads from it, after the previous one has already closed 
it, then it will read the new contents ... from the buffers, from the disk, 
from wherever.

 This is about syncing the data contents to the disk, i.e. writing them and 
waiting for the write to finish, as an attempt to ensure the config file is 
never destroyed (lost contents, both old and new).

 BTW, I've already talked to the kernel developer I had wanted to talk to. 
According to him, POSIX really allows XFS to have the stupid behaviour of 
writing the metadata change before writing the contents and thrashing the 
file. He considered it to be, IIRC, "not very wise" and "favouring 
performance over correctness" (or something like that). As somebody has said 
already in this thread, we should prefer correctness to performance, and as 
such I don't see strong urge to play as XFS wishes. E.g. with ext3 there's no 
such problem, unless one explicitly selects journal=writeback.

 There are more important things to do now (like 4.0 :) ), but I'll somewhen 
make the explicit sync only optional (unless somebody else does). Something 
like a kcminit module detecting such filesystems and setting $KDE_EXTRA_SYNC 
and KSaveFile doing the sync only in such case. We could do either simply 
nothing in the case of other filesystems or perhaps go with only 
sync_file_range() with SYNC_FILE_RANGE_WRITE.

-- 
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]