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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).