On Sep 30, 2009, at 12:23 46PM, Aaron J. Grier wrote:
On Tue, Sep 29, 2009 at 04:51:22PM -0700, Dieter wrote:From the discussion softdeps obviously works well for others, it isn't just me.There is no reason to remove softdeps. It is optional, those who don't like it don't have to run it.just like nobody can force you to a newer version of NetBSD, you can't force the maintainers to continue dealing with the softdeps code. they don't want to deal with the maintenance. do you?
I'd have phrased it somewhat differently, but in essence you're correct.Keeping the code around and even half-way working has a cost. When you change something in, say, the file system code, you have to make sure that you update all relevant pieces of code. Softdeps have never worked reliably. They work for some people, but not for everyone, and the code has resisted fixing. What should the community do?
Effort spent trying to keep softdeps working is effort that can't be spent on something else. We know from experience that we're not likely to be able to get it working correctly. EVen if we don't want to touch it because its current state of (dis)repair is good enough, we still have to look at it when we do other things to the file system. (I'll make up a hypothetical example. Suppose I wanted to add more metadata to files to help with autosyncing between a desktop and a laptop. When does that data get written out in a softdep environment? Does it matter? That's more time and effort I have to spend, solely because of the existence of the feature. *And* that feature doesn't work well, and is used by fewer and fewer people because of its bugs.
There's no perfect answer, and it's not related to developers not wanting to support a feature. It's a question of how to apply limited resources. The decision here is to cut our losses -- eliminate the code, and install something else that is believed to work better and will satisfy many (but probably not all) of the needs that softdeps was filling.
--Steve Bellovin, http://www.cs.columbia.edu/~smb