From: Chris Mason <chris.mason@oracle.com>
To: Jeff Mahoney <jeffm@suse.de>
Cc: Liu Bo <liubo2009@cn.fujitsu.com>, Jeff Mahoney <jeffm@suse.com>,
Mark Fasheh <mfasheh@suse.de>,
Btrfs Development List <linux-btrfs@vger.kernel.org>
Subject: Re: Error handling: How to "lose" a transaction
Date: Fri, 23 Dec 2011 09:17:31 -0500 [thread overview]
Message-ID: <20111223141731.GS19266@shiny> (raw)
In-Reply-To: <4EF40DBF.4070505@suse.de>
On Fri, Dec 23, 2011 at 12:12:31AM -0500, Jeff Mahoney wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 12/21/2011 10:38 PM, Jeff Mahoney wrote:
> > On 12/21/2011 10:21 PM, Liu Bo wrote:
> >> On 12/22/2011 10:59 AM, Jeff Mahoney wrote: Sorry I haven't
> >> responded to this yet. I started digging right in and I've
> >> started to have some good results. It turns out there's already a
> >> btrfs_cleanup_transaction call that will tear down outstanding
> >> transactions. It's not perfect and I've fixed a few bugs in
> >> there, but it saved me a bunch of effort. I just wished I noticed
> >> it a day before since I had it half implemented myself. :)
> >
> >
> >>> Hi Jeff,
> >
> >>> Yes, it should be, and I wrote this cleanup_transaction where
> >>> I should notice you earlier... Anyway, thanks for your effort.
> >
> >>> The error handling part has lots of corner cases, so I just
> >>> pick up a brute way to tear down the current transaction in
> >>> order to make the FS RO.
> >
> > Oh, and it's worked great. The brute force method is a good start
> > and will address the most severe problems (and most cases) well.
> > I've decided to ignore most cases of -ENOMEM for now. The biggest
> > bug I ran into so far was calling mutex_lock while holding a
> > spinlock. It was a quick fix.
> >
> > The method I've generally used is to mark the transaction aborted
> > and pass the error up as quickly as possible, cleaning up the
> > local allocations and locks as I go. The transaction gets
> > completed normally, returns an error, isn't committed, and then is
> > destroyed (with others, potentially) when called from in
> > btrfs_commit_transaction. Btrfs makes this super easy since we can
> > just skip all the CoW writes.
>
>
> Now, just out of curiosity, would it be ok if I printed this when we
> ran out memory in deep call paths?
>
> FAIL WHALE!
>
> W W W
> W W W W
> '. W
> .-""-._ \ \.--|
> / "-..__) .-'
> | _ /
> \'-.__, .__.,'
> `'----'._\--'
> VVVVVVVVVVVVVVVVVVVVV
>
>
> Happy Holidays ;)
I'll take any patch you put into the suse kernel ;)
-chris
prev parent reply other threads:[~2011-12-23 14:17 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-13 21:47 Error handling: How to "lose" a transaction Jeff Mahoney
2011-12-14 0:13 ` Chris Mason
2011-12-22 2:59 ` Jeff Mahoney
2011-12-22 3:21 ` Liu Bo
2011-12-22 3:38 ` Jeff Mahoney
2011-12-23 5:12 ` Jeff Mahoney
2011-12-23 5:43 ` Liu Bo
2011-12-23 14:17 ` Chris Mason [this message]
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=20111223141731.GS19266@shiny \
--to=chris.mason@oracle.com \
--cc=jeffm@suse.com \
--cc=jeffm@suse.de \
--cc=linux-btrfs@vger.kernel.org \
--cc=liubo2009@cn.fujitsu.com \
--cc=mfasheh@suse.de \
/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.