All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Steigerwald <Martin@lichtvoll.de>
To: linux-xfs@oss.sgi.com
Cc: "Felix E. Klee" <felix.klee@inka.de>, Iustin Pop <iusty@k1024.org>
Subject: Re: Data safety horror stories?
Date: Mon, 18 Feb 2008 22:28:45 +0100	[thread overview]
Message-ID: <200802182228.50631.Martin@lichtvoll.de> (raw)
In-Reply-To: <1202764989.11126.1236296081@webmail.messagingengine.com>

[-- Attachment #1: Type: text/plain, Size: 1742 bytes --]

Am Montag 11 Februar 2008 schrieb Felix E. Klee:
> Hi Justin,

Hi Felix,

> > Improperly written applications and/or improperly configured systems
> > might have issues with recently written files losing data.
>
> Again, just to make sure that I understood you correctly: Could you
> name an example?

I recommend to read my article about write barriers and journalling 
filesystems for some basic understanding.
 
http://www.linux-magazin.de/heft_abo/sonderheft/2006/04/beschraenktes_schreiben?category=0

its in german tough. Actually I thought it should have been translated to 
english for Linux Magazine under the title "Imposing Order", but I do not 
find it on the net and it might have not been published.

Note: There is a mistake in it regarding history of write barriers. Write 
barriers are not supported via device mapper. Thats why I do not use LVM 
on my notebook for my productive data.

> > Just my opinion as an XFS user, your mileage might vary.
>
> Hopefully, it's not about opinions ...

I had not had any problems since quite some kernel releases. And there 
were some power losses involved ;). At earlier times Akregator (an KDE 
newsreader) said its opml was broken and a backup was restored after such 
a power loss... but not since quite some kernel releases.

I had one nasty problem with corrupt data in files but that was with a 
kernel that was patched with Con Koliva's patchset and didn't happen in 
mainline.

So since 2.6.17.7 XFS has been pretty stable for me. On a ThinkPad T42, a 
ThinkPad T23 and half a dozen of workstations at work ;-).

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2008-02-18 21:28 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-11 16:46 Data safety horror stories? Felix E. Klee
2008-02-11 17:12 ` Iustin Pop
2008-02-11 21:23   ` Felix E. Klee
2008-02-18 21:28     ` Martin Steigerwald [this message]
2008-02-18 21:41       ` Felix E. Klee
2008-02-18 21:49         ` Martin Steigerwald
2008-02-18 22:50     ` David Chinner
2008-02-11 22:03 ` David Chinner

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=200802182228.50631.Martin@lichtvoll.de \
    --to=martin@lichtvoll.de \
    --cc=felix.klee@inka.de \
    --cc=iusty@k1024.org \
    --cc=linux-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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.