[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Safe file update library ready (sort of)



On Fri, Jan 28, 2011 at 3:26 AM, Ted Ts'o <tytso@mit.edu> wrote:
> On Wed, Jan 26, 2011 at 06:14:42PM +0100, Olaf van der Spek wrote:
>> On Wed, Jan 26, 2011 at 5:36 PM, Hendrik Sattler
>> <post@hendrik-sattler.de> wrote:
>> > BTW: KDE4 is a very good example for failure with modern filesystems. I
>> > regularly loose configuration files when suspend-to-ram fails even if the
>> > configuration of the running programs were not changed. Yay :-( And this is
>> > with XFS, not Ext4! Filed a bug a looooooong time ago in KDE BTS. Reaction:
>> > none!
>>
>> Maybe complain to the Linux kernel people instead.
>
> It won't be just XFS or ext4, but any file system except ext3 (which
> has performance problems specifically *because* of an implementation
> detail accidentally provided this feature you like), and I think what
> you'll find is that most Linux kernel developers will tell you is that
> it's a bug in the application.
>
> If you don't like that answer, you'll find that it's true for any
> other OS (i.e., BSD, OpenSolaris, etc.)  --- so either KDE needs to
> get with the program, or find its users gradually switching to other
> windowing systems that have sanely written libraries.
>
>                                                - Ted
>
> P.S.  There is a kernel options that provide improved ext3
> performance, to wit, CONFIG_EXT3_DEFAULTS_TO_ORDERED=no, which will
> also mean that you had better use fsync() if you want files pushed out
> to disk.  So strictly speaking, it's not even true that KDE4 is
> guaranteed to be safe if you use ext3.

Is there a way to log cases where (potentially) unsafe writes happen?
Cases like truncation of an existing file, rename on a target that's
not yet synced, etc.


-- 
Olaf


Reply to: