Re: Error handling: How to "lose" a transaction

[Jeff Mahoney <jeffm@suse.de>]

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

- -Jeff

> 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
>>> 
> 
> 
> -- 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/

iQIcBAEBAgAGBQJO9A2/AAoJEB57S2MheeWyiNIP/3Z6NETIXskkp+OVKTiF/gaP
bopj2dp92BlURFHEj5vJoESm4cUtQKTx9J/DB3yc7JDzc0UcRs9KCqGV9UpH6y9/
Zetzy3ZMsYyxvV5CZ50NGr+C1r5ULVGQ/UrPex/GT0bApcdBRMkFASLH8xkFl6dE
dfRjir038GzjVX/Phy0VPm0mg8eg77aco11Xk2+Y1MdEhsEqI+cUQYgA8O9M7HWy
67Vv3KWxKC7PU6SYCPa0wGmQwTgs10GuKT9w+s7Ampy8iQhCgEuDo4dQxpRehQfp
YwD/vlHwVATTAR2zMbRtI0BWa+ideBzcdQg1QrZxB3o026Z7ooy+/fTqS6MiUrXy
mxGvb0g/BglK6Q86YQE77doIfJeUDLGoGQx2Zv1S9OzVwigo1a0LcP82P7yNnJBY
oihql+FAYBXwjqiAQ+wUvo7wy0H+ltmQgWfUDf5wjDHquTRT1H0kE15Okc8MX8+T
rmhp6vD1deX5Jz+JBIpCm94JhxUBPkBH2WksyA1jdLUOngHxRI0jmqz/5mPexV8e
dChaq1rsjYs5Zbbv/jpaefnEw0kbZ0cqS7uDLVVoyjEqGnBpqjdwE86WYjxc4biM
MkeSJ67Oof3ZGLWR0VQ+h4YnRjqAsMWsEd3jBLMo2krsr8ucc/UOzVDBVojDlGWJ
Z2HunZuWJkNgcsBatVoS
=z1sd
-----END PGP SIGNATURE-----