On 12/23/2011 01:12 PM, 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? >
I'm ok with this, but it depends on Chris :) Indeed, ENOMEM in deep call paths is a big big trouble for us, we don't yet have a graceful solution, and we can make an memory allocation with mask __GFP_NOFAIL flags for simplicity, although it is not recommended: * __GFP_NOFAIL: The VM implementation _must_ retry infinitely: the caller * cannot handle allocation failures. This modifier is deprecated and no new * users should be added. > FAIL WHALE! > > W W W > W W W W > '. W > .-""-._ \ \.--| > / "-..__) .-' > | _ / > \'-.__, .__.,' > `'----'._\--' > VVVVVVVVVVVVVVVVVVVVV > > > Happy Holidays ;) > Happy Holidays! thanks, liubo > - -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 >>>> majord...@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 majord...@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----- > -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
