Re: fsync() madness

["Andreas Hartmetz" <ahartmetz@xxxxxxxxx>]

2008/4/21, Uwe Thiem <uwix@xxxxxxx>:

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.
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<