All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Mahoney <jeffm@suse.de>
To: Liu Bo <liubo2009@cn.fujitsu.com>
Cc: Chris Mason <chris.mason@oracle.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: Wed, 21 Dec 2011 22:38:41 -0500	[thread overview]
Message-ID: <4EF2A641.7070308@suse.de> (raw)
In-Reply-To: <4EF2A24D.7040501@cn.fujitsu.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

Thanks!

- -Jeff


>> thanks, liubo
> 
> This afternoon I started running xfstests on a dm-linear mapped 
> partition. Halfway through a sufficiently long test, I swap out
> the linear mapping to an error mapping. It still crashes, but
> somewhat less spectacularly. There are still a ton of BUG_ON's I
> need to eliminate as well as work out the usual I/O error-recovery
> issue of uninterruptible, unrecoverable writeback contexts and
> still-locked pages holding up exit. I'm pretty pleased with the
> results so far and am pretty optimistic.
> 
> -Jeff
> 
> 
>> -- To unsubscribe from this list: send the line "unsubscribe
>> linux-btrfs" in the body of a message to
>> majordomo@vger.kernel.org More majordomo info at
>> http://vger.kernel.org/majordomo-info.html
>> 
> 

- -- 
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJO8qZBAAoJEB57S2MheeWyCtYP/0+VGdUrdPceYkMGngweINFI
Y6K/xzDG2tiogFyb8mVj4XH9xtGoODWiZ+yb2FkRfoqsq1dS34/XzM1Cf1SBgFTu
J8xIxv3gVp0lDycV6QqpetNaPPpxDz61LmiFqNRd6bn/usBoYdlyexX3HmPll7Je
MS0uAiUVNTJIK+W3qN9BIyvg8F61XFy3SdeCY5dmzClDJft1dgu6mWlHhcKVL7LW
uDrX9vldV56qoL6rrNyR/wBVg8rhMxVN5z9qFttWsSpORwZdIOIUdKiTULqnCdvf
mzs1yNAsAMTcE0GCLOIWEyiTSZrDlg4nGgZMIDKnzD0GywJDy+qc/9XPL+5WkyaD
Z48a6sBCXGhmQsux8iEeGAlTfP5/YJMd2PqaKfFlpSeL2u+Pt6EAFUpEUfXDYRhI
aBxzJK7D+GrgduheWTQc2AgeH8ee7bUEe1k+d4+EIWJTq5vKkPWH7x580q0yL+t2
qiLqzSlSTPaCr9tJlQo3d+dHu2L2r43+2qYeHut0JjFtp2dDjWO7AzcQ2JsL0yZR
jL0dVT96OsWkmKu/qfvSbFZ6LLR+QrlqBzTgNA4R69nLlUj1f05AVaYvwuVqnIPH
QdCf53kaEjvVlRw2WScsRHT1gMY62jmES0glIBgAH9bKAYKADlnzIAW6RSpB8NcO
GZoCa+90OHl/kkXWB2eZ
=DR3D
-----END PGP SIGNATURE-----

  reply	other threads:[~2011-12-22  3:38 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 [this message]
2011-12-23  5:12         ` Jeff Mahoney
2011-12-23  5:43           ` Liu Bo
2011-12-23 14:17           ` 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=4EF2A641.7070308@suse.de \
    --to=jeffm@suse.de \
    --cc=chris.mason@oracle.com \
    --cc=jeffm@suse.com \
    --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.