Comment 205 for bug 330824

I want to apologize for my last comment. I really like having a free operating system and all the free software, and I love the people who volunteer their time putting it all together and making it work as well as it does (thank you!). I was in a bit of a mood after messing with this thing all night.

I use Ubuntu because I am lazy. I don't go out of my way to install the newest cutting edge stuff because I would rather not be the one who spends his hours sifting through these forums / the source / git bisect / etc. I'd rather benefit from the hard work of the people who like to do that stuff (thanks again!) So once every year or so, whenever I get a new drive or update some hardware in some significant way, I go to the Ubuntu website and download the latest installation image, and usually only after it's been out a few months. With minimal faffing I have my system up and running in half an hour or so, all my old data happily copying over to the new system. I never read release notes, things just work (well, laptops usually need a little tweaking).

I had no idea this last time that when I installed 9.04 that selecting ext4 was in any way dangerous or experimental. Deviating away from the "stable defaults that Ubuntu provides" was as easy as cursoring up (or down, I don't remember) from ext3 to ext4. I saw the option, thought to myself, "cool, it's here, this is Ubuntu, it must be working well" why not use ext4 vs. ext3? I had no idea that I was doing something even slightly risky, because there was nothing in the lazy man's path from download to having a running system that would have told me so. If there was, I would have gone ext3 and I never would have read this thread and you wouldn't be wasting your time reading this right now. From now on, I'll read the release notes and hopefully save us all some time. I'd like to be more lazy, but there simply isn't a better option than Ubuntu right now.

So lazy talk aside, I'd actually like to be more helpful when these things come up. This particular case looks (from the tiny bit I have seen) like a classic deadlock. In the codebase I am most familiar with, it's pretty simple to turn on traces for locks that you know are in contention and use the trace to find the culprit. It's been almost ten years since I've done any significant work in the Linux kernel, however, so I'd have to do some ramping up. Anyone have pointers to your favorite kernel hacking resources (I'm sure even the basic tools have changed a lot in 10 years) in case I find myself motivated and with some time on my hands?

Thanks,
Jason