From kde-devel Mon Apr 21 16:17:26 2008 From: "Andreas Hartmetz" Date: Mon, 21 Apr 2008 16:17:26 +0000 To: kde-devel Subject: Re: fsync() madness Message-Id: X-MARC-Message: https://marc.info/?l=kde-devel&m=120879476621629 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============0891572988==" --===============0891572988== Content-Type: multipart/alternative; boundary="----=_Part_3133_15509521.1208794646211" ------=_Part_3133_15509521.1208794646211 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 2008/4/21, Uwe Thiem : > > 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. ------=_Part_3133_15509521.1208794646211 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

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.
------=_Part_3133_15509521.1208794646211-- --===============0891572988== 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 << --===============0891572988==--