From: Chris Mason <chris.mason@oracle.com>
To: Lubos Kolouch <lubos.kolouch@gmail.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: Question of stability
Date: Wed, 22 Sep 2010 18:50:29 -0400 [thread overview]
Message-ID: <20100922225029.GA2309@think> (raw)
In-Reply-To: <i7d2e9$147$1@dough.gmane.org>
On Wed, Sep 22, 2010 at 02:04:57PM +0000, Lubos Kolouch wrote:
> Chris Mason, Mon, 20 Sep 2010 08:13:07 -0400:
>
> > On Mon, Sep 20, 2010 at 12:10:08PM +0000, Lubos Kolouch wrote:
> >> On Mon, 20 Sep 2010 07:30:57 -0400, Chris Mason wrote:
> >>
> >> > On Mon, Sep 20, 2010 at 11:00:08AM +0000, Lubos Kolouch wrote:
> >> >> No, not stable!
> >> >>
> >> >> Again, after powerloss, I have *two* damaged btrfs filesystems.
> >> >
> >> > Please tell me more about your system. I do extensive power fail
> >> > testing here without problems, and corruptions after powerloss are
> >> > very often caused by the actual hardware.
> >> >
> >> > So, what kind of drives do you have, do they have writeback caching
> >> > on, and what are you layering on top of the drive between btrfs and
> >> > the kernel?
> >> >
> >> > -chris
> >> >
> >> >
> >> Hello Chris,
> >>
> >> The system is running with 128GB SDD Samsung disk. The partition is
> >> encrypted with LUKS and on top btrfs filesystem is created.
> >
> > Ok, we're seeing consistent reports of corruptions after power failure
> > with dm-crypt. The barriers must not be getting down to the device.
> >
> >
> >> The backup disk is a 160GB WD notebook disk connected via IDE->USB
> >> cable, whole formatted with LUKS and btrfs on top.
> >>
> >> Actually, if there was any way (non-standard) how to mount the system
> >> and recover even part of the data, I would be very grateful.
> >
> > We can definitely try. Please send me email with the errors from
> > btrfsck and I'll work on a patch that gets you read only access.
>
> Just for the record - thanks to Chris I could recover the data in read-
> only mode, thanks again.
>
> So are there any recommendations (mount options etc.) for running btrfs
> on LUKS encrypted partition?
I would suggest turning off the drives writeback cache. hdparm -W 0, it
must be run after every boot.
-chris
next prev parent reply other threads:[~2010-09-22 22:50 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-18 21:37 Question of stability Roy Sigurd Karlsbakk
2010-09-18 21:55 ` Hendrik Fabelje
2010-09-18 23:55 ` Roy Sigurd Karlsbakk
2010-09-19 0:43 ` C Anthony Risinger
2010-09-19 2:00 ` Roy Sigurd Karlsbakk
2010-09-19 4:50 ` C Anthony Risinger
2010-09-20 15:12 ` K. Richard Pixley
2010-09-20 15:27 ` C Anthony Risinger
2010-09-19 9:51 ` Hugo Mills
2010-09-20 1:18 ` Chris Samuel
2010-09-20 11:00 ` Lubos Kolouch
2010-09-20 11:30 ` Chris Mason
2010-09-20 12:10 ` Lubos Kolouch
2010-09-20 12:13 ` Chris Mason
2010-09-22 14:04 ` Lubos Kolouch
2010-09-22 22:50 ` Chris Mason [this message]
2010-09-20 12:21 ` Stephan von Krawczynski
2010-09-20 12:27 ` Chris Mason
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=20100922225029.GA2309@think \
--to=chris.mason@oracle.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=lubos.kolouch@gmail.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.