[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-21 16:17:26
Message-ID: f3642e6b0804210917o4a515cbbod7b750ca9bae4da6 () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
2008/4/21, Uwe Thiem <uwix@iway.na>:
>
> On Monday 21 April 2008, Sami Liedes wrote:
> > On Mon, Apr 21, 2008 at 08:25:47AM -0700, Gary Greene wrote:
> > > On Monday 21 April 2008 8:15:51 am Sami Liedes wrote:
> > > > On Mon, Apr 21, 2008 at 02:11:40PM +0200, Lubos Lunak wrote:
> > > > > On Sunday 20 of April 2008, Sami Liedes wrote:
> > > > > > I had missed that post. Still, no analysis of the
> > > > > > performance hit there, and I think the attitude of "no data
> > > > > > loss at all allowed at any power loss, implement at any
> > > > > > cost to performance" is misguided.
> > > > >
> > > > > Tell that to XFS developers and their users. Anyway, where's
> > > > > your patch?
> > > >
> > > > The patch is simple and not very fine grained, but effective
> > > > and shouldn't break anything unless a power loss happens.
> > > > Attached.
> > > >
> > > > Sami
> > >
> > > Again you are not taking into account XFS. How many times must we
> > > iterate over this.... _If you don't have the code check which FS
> > > this is on and PROPERLY deal with this, you will kill users
> > > data._
> >
> > Without a power loss? I don't think so. And data loss on power loss
> > is expected to happen on any write back caching fs (i.e. not
> > mounted noasync) on power loss. Care to still iterate once?
>
>
> Sync or no, no filesystem can completely avoid data loss or even FS
> corruption on power cuts. That is so because all modern harddrives
> come with internal caches. Whatever the FS does, those internal
> caches can be dirty at the time of a power cut.
>
>
According to hdparm hardware write caching is off by default. If that is
actually true right down to the metal is another topic. But IMHO we should
just admit that data loss is not 100% avoidable and that you should have
backups for very important data. Config files are often not all that
important, even.
[Attachment #5 (text/html)]
<br><br><div><span class="gmail_quote">2008/4/21, Uwe Thiem <<a \
href="mailto:uwix@iway.na">uwix@iway.na</a>>:</span><blockquote \
class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt \
0pt 0.8ex; padding-left: 1ex;"> On Monday 21 April 2008, Sami Liedes wrote:<br> > \
On Mon, Apr 21, 2008 at 08:25:47AM -0700, Gary Greene wrote:<br> > > On Monday \
21 April 2008 8:15:51 am Sami Liedes wrote:<br> > > > On Mon, Apr 21, 2008 \
at 02:11:40PM +0200, Lubos Lunak wrote:<br> > > > > On Sunday 20 of \
April 2008, Sami Liedes wrote:<br> > > > > > I had missed that post. \
Still, no analysis of the<br> > > > > > performance hit there, and I \
think the attitude of "no data<br> > > > > > loss at all allowed \
at any power loss, implement at any<br> > > > > > cost to \
performance" is misguided.<br> > > > ><br> > > > \
> Tell that to XFS developers and their users. Anyway, where's<br> \
> > > > your patch?<br> > > ><br> > > > The patch is \
simple and not very fine grained, but effective<br> > > > and shouldn't \
break anything unless a power loss happens.<br> > > > Attached.<br> > \
> ><br> > > > Sami<br> > ><br> > > Again you \
are not taking into account XFS. How many times must we<br> > > iterate over \
this.... _If you don't have the code check which FS<br> > > this is on and \
PROPERLY deal with this, you will kill users<br> > > data._<br> ><br> > \
Without a power loss? I don't think so. And data loss on power loss<br> > is \
expected to happen on any write back caching fs (i.e. not<br> > mounted noasync) \
on power loss. Care to still iterate once?<br> <br> <br>Sync or no, no filesystem can \
completely avoid data loss or even FS<br> corruption on power cuts. That is so \
because all modern harddrives<br> come with internal caches. Whatever the FS does, \
those internal<br> caches can be dirty at the time of a power cut.<br> \
<br></blockquote></div><br>According to hdparm hardware write caching is off by \
default. If that is actually true right down to the metal is another topic. But IMHO \
we should just admit that data loss is not 100% avoidable and that you should have \
backups for very important data. Config files are often not all that important, \
even.<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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic