public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Martin Steigerwald <Martin@lichtvoll.de>
To: xfs@oss.sgi.com
Subject: safe writing in applications (was: Re: massively truncated files with XFS with sudden power loss on 2.6.27 and 2.6.28)
Date: Mon, 29 Dec 2008 20:48:40 +0100	[thread overview]
Message-ID: <200812292048.41193.Martin@lichtvoll.de> (raw)
In-Reply-To: <200812291920.34123.Martin@Lichtvoll.de>

Am Montag 29 Dezember 2008 schrieb Martin Steigerwald:
> Hi!
> Remember
>
> http://oss.sgi.com/pipermail/xfs/2008-November/037399.html
>
> ?

[... about truncated KDE configuration files ...]

> I cannot remember having seen this kind of behavior anywhere between
> 2.6.17.7 and 2.6.26! And I had sudden interruptions of write activity
> from time to time.
>
> I can't prove anything right now. I possibly could if I dare to test
> this again with 2.6.26! But from my experiences this never was so
> massive. Prior to the null file fixes a file or two might have been
> corrupted and that not all the times. Thats to be expected if thats the
> file that where written out at the time. But now it seems that almost
> every file that is opened for writing or not even just for writing is
> truncated seriously at sudden interruption of write activity. Whereas
> before it appeared that usually either the change was not made or it
> was made - at least for small files. Now the file is truncated, no
> holes, just lots less bytes than before.

Ok, I had to test this. So I made a backup of my current KDE configuration 
to an external drive and tested with 2.6.25.10 and 2.6.26.5! It happens 
there too. So its nothing new what I have observed here. Even the case of 
massively truncated files when trying directly after KDE login. Why all 
those applications appear to write out their configurations files when 
just having been started is a bit beyond me, but well that seems to be 
the case.

So it seems with pre 2.6.27 and 2.6.28 sudden power interruptions I had 
*lots of luck*. Or there is a very subtile difference in the likelyhood 
of truncated files happening. I had the impression during my todays test 
that at least with 2.6.25.10 and 2.6.26.5 truncated files were a little 
less likely, but I have no means of statistics.

And I do not yet have a comparison with ext3/ext4 either.

So I jumped out of the window with my conclusions too early, or I need to 
test even earlier kernels. I hold back an earlier mail about this 
already, but this time I thought I'd write an email. Sorry for the noise.

It might be wise however to file enhancement requests for the KDE 
applications where I observed this behavior if safer writing within the 
applications is possible. Any hints on what application developers should 
keep in mind when writing out config files?

Ciao,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  parent reply	other threads:[~2008-12-29 19:48 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-29 18:20 massively truncated files with XFS with sudden power loss on 2.6.27 and 2.6.28 Martin Steigerwald
2008-12-29 19:03 ` Chris Wedgwood
2008-12-29 19:08 ` Eric Sandeen
2008-12-29 20:00   ` Martin Steigerwald
2008-12-30  0:14   ` Chris Wedgwood
2008-12-29 19:09 ` Russell Cattelan
2008-12-29 19:20   ` Christoph Hellwig
2008-12-29 19:29   ` Chris Wedgwood
2008-12-29 20:09     ` Russell Cattelan
2008-12-29 20:17       ` Chris Wedgwood
2008-12-29 21:25         ` Russell Cattelan
2008-12-29 21:56       ` Eric Sandeen
2008-12-29 19:48 ` Martin Steigerwald [this message]
2008-12-29 19:54   ` safe writing in applications (was: Re: massively truncated files with XFS with sudden power loss on 2.6.27 and 2.6.28) Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200812292048.41193.Martin@lichtvoll.de \
    --to=martin@lichtvoll.de \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox