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

List:       kde-devel
Subject:    Re: fsync() madness
From:       "Andreas Hartmetz" <ahartmetz () gmail ! com>
Date:       2008-04-22 11:43:19
Message-ID: f3642e6b0804220443h1b3c860co52c37804d6e63613 () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


2008/4/22 David Jarvie <djarvie@kde.org>:

> On Monday 21 April 2008 20:38, Esben Mose Hansen wrote:
> > I discussed this with a friend (who liked XFS because it could online
> grow
> > >:)
> > ) and it seems that the worst part of XFS behaviour in this regard was
> > fixed
> > in 2.6.22 --- the bit where any dirty file was zeroed just to be
> sure(!).
> > So
> > maybe we don't have to sync() quite so much now.  He has tested it a lot
> > of
> > times by installing a bios that crashed linux all the time, and it seems
> > to work much better now :)
>
> The fact that the XFS problems were a bug which has now been fixed is
> surely a good illustration of why KDE should not concern itself with OS or
> file system details. It should leave decisions about whether to sync to
> disc to the OS. If there's a problem at that level, it's a system-wide
> problem which needs to be fixed outside KDE.
>
> If KDE tries to preempt OS implementation details like this, it will not
> only (as in this case) reduce performance for everybody, but it will also
> prevent OS/filesystem improvements, when they occur, from feeding through
> to give benefits to the KDE user.
>
>
I couldn't agree more. When you enable laptop mode, for example, you make a
conscious decision to lose some safety for longer battery life (*). This
will not work when an upper layer tries to, as somebody put it, second-guess
the OS. There is the ocassional strong reason to do that but I can't see it
here.

(*) "Let's integrate that into KPowersave then!" some might say. I don't.
It's more maintenance for, IMHO, little benefit over just letting the kernel
do its thing.

[Attachment #5 (text/html)]

<br><br><div class="gmail_quote">2008/4/22 David Jarvie &lt;<a \
href="mailto:djarvie@kde.org">djarvie@kde.org</a>&gt;:<br><blockquote \
class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt \
0pt 0.8ex; padding-left: 1ex;"> <div class="Ih2E3d">On Monday 21 April 2008 20:38, \
Esben Mose Hansen wrote:<br> &gt; I discussed this with a friend (who liked XFS \
because it could online grow<br> &gt; &gt;:)<br>
&gt; ) and it seems that the worst part of XFS behaviour in this regard was<br>
&gt; fixed<br>
&gt; in 2.6.22 --- the bit where any dirty file was zeroed just to be sure(!).<br>
&gt; So<br>
&gt; maybe we don&#39;t have to sync() quite so much now. &nbsp;He has tested it a \
lot<br> &gt; of<br>
&gt; times by installing a bios that crashed linux all the time, and it seems<br>
&gt; to work much better now :)<br>
<br>
</div>The fact that the XFS problems were a bug which has now been fixed is<br>
surely a good illustration of why KDE should not concern itself with OS or<br>
file system details. It should leave decisions about whether to sync to<br>
disc to the OS. If there&#39;s a problem at that level, it&#39;s a system-wide<br>
problem which needs to be fixed outside KDE.<br>
<br>
If KDE tries to preempt OS implementation details like this, it will not<br>
only (as in this case) reduce performance for everybody, but it will also<br>
prevent OS/filesystem improvements, when they occur, from feeding through<br>
to give benefits to the KDE user.<br>
<font color="#888888"><br></font></blockquote></div><br>I couldn&#39;t agree more. \
When you enable laptop mode, for example, you make a conscious decision to lose some \
safety for longer battery life (*). This will not work when an upper layer tries to, \
as somebody put it, second-guess the OS. There is the ocassional strong reason to do \
that but I can&#39;t see it here.<br> <br>(*) &quot;Let&#39;s integrate that into \
KPowersave then!&quot; some might say. I don&#39;t. It&#39;s more maintenance for, \
IMHO, little benefit over just letting the kernel do its thing.<br>



>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


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