-----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@xxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxx
> 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-----
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
