Whither btrfsck?

The problem is that people do have this attitude. I work with developers who don't like Red Hat because of what they did in 1999. I work with people who prefer Debian because of "RPM Hell". I've worked with people who hate Perl because of the quality of code written in Perl 3. I've worked with people who have sworn never to use a Seagate disk because of that great problem they had back in 2003 or whatever.

To repurpose http://xkcd.com/242/, maybe scientists can afford the time to see if the same problem happens again later. But sysadmins and programmers tend to be under pressure to produce results, and lots of them can't afford the time to retest their assumptions later. The better ones I've seen test new things out or test their assumptions out at home or on test systems in spare time. The cowboys test them on live systems in production and then wonder why everyone gets upset.

I agree we should all be able to test out btrfsck and have the code in the open so that people can contribute ideas about those corner cases and weird fuzzy problems that Chris might not have thought about. But if there are already people complaining that btrfs is eating their data, then releasing btrfsck early and buggy is only going to hurt its reputation. That's why I support Chris's decision to hold onto it for now. I'm sure he's trying to do the right thing but it's his decision to make.

Have fun,

Paul