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

List:       kde-devel
Subject:    Re: fsync() madness
From:       Uwe Thiem <uwix () iway ! na>
Date:       2008-04-21 16:11:04
Message-ID: 200804211711.04774.uwix () iway ! na
[Download RAW message or body]

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.

Uwe

-- 
Informal Linux Group Namibia:
http://www.linux.org.na/
SysEx (Pty) Ltd.:
http://www.SysEx.com.na/
 
>> 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