linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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


      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).