From: pg_xf2@xf2.sabi.co.UK (Peter Grandi)
To: Linux XFS <xfs@oss.sgi.com>
Subject: Re: zero size file after power failure with kernel 2.6.30.5
Date: Mon, 31 Aug 2009 23:10:44 +0000 [thread overview]
Message-ID: <19100.22644.149019.555685@tree.ty.sabi.co.uk> (raw)
In-Reply-To: <4A99A80C.9010307@sandeen.net>
[ ... ]
>> Shouldn't it be that this doesn't happen anymore? I'd love to
>> be in a position where I really can rely on a crash not
>> trashing any of my files anymore.
Then 'mount' with '-o sync', or write your own applications and
patches to the GNU/Linux kernel to enforce well known atomicity
and persistence semantics.
This issue as related to several filesystems has been discussed
in great depth over the past several months. Consider reading
and if possible try to understand these contributions:
http://sandeen.net/wordpress/?p=34
http://sandeen.net/wordpress/?p=42
https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/317781/comments/45
http://lwn.net/SubscriberLink/322823/e6979f02e5a73feb/
http://loupgaroublond.blogspot.com/2009/03/anecdote-about-why-doing-wrong-thing-is.html
http://thunk.org/tytso/blog/2009/03/12/delayed-allocation-and-the-zero-length-file-problem/
http://mjg59.livejournal.com/108257.html
http://www.csamuel.org/2009/04/11/default-ext3-mode-changing-in-2630
http://tribulaciones.org/2009/03/is-ext4-unsafe/
>> I used to have reiserfs previously, and never, not a single
>> time despite many crashes, did I have such an issue. I'd
>> really be pleased so see such stability in XFS. I'm using
>> barriers - what else must I do?
Barriers under GNU/Linux regrettably only enforce ordering. It
is a POSIX weakness. Actual delays/semantics depend on kernel
version.
> this will depend on what kde is doing internally as well.
Unfortunately KDE like most applications is known not to do the
right thing (depending on specific app and version, but most IIRC).
[ ... ]
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2009-08-31 23:10 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-29 19:02 zero size file after power failure with kernel 2.6.30.5 Michael Monnerie
2009-08-29 22:13 ` Eric Sandeen
2009-08-31 23:10 ` Peter Grandi [this message]
2009-09-01 7:18 ` Michael Monnerie
2009-09-01 10:32 ` Peter Grandi
2009-09-01 14:19 ` Emmanuel Florac
2009-09-01 22:52 ` Michael Monnerie
[not found] ` <alpine.DEB.2.00.0908291517350.24777@p34.internal.lan>
2009-08-30 8:39 ` Michael Monnerie
2009-09-18 20:05 ` Martin Steigerwald
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=19100.22644.149019.555685@tree.ty.sabi.co.uk \
--to=pg_xf2@xf2.sabi.co.uk \
--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