--===============0154908660== Content-Type: multipart/alternative; boundary="----=_Part_8034_15546841.1208864599214" ------=_Part_8034_15546841.1208864599214 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 2008/4/22 David Jarvie : > 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. ------=_Part_8034_15546841.1208864599214 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

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.
------=_Part_8034_15546841.1208864599214-- --===============0154908660== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe << --===============0154908660==--