quota deadlock on 6.1-RC1

David Kirchner dpk at dpk.net
Thu May 4 03:30:29 UTC 2006

On 5/3/06, Kris Kennaway <kris at obsecurity.org> wrote:
> On Wed, May 03, 2006 at 06:21:39PM -0700, David Kirchner wrote:
> > However, one could argue that as quotas worked OK in releases prior to
> > 6.0 (and perhaps earlier), that there is a longer-term regression.
> There was a quota regression in 6.0.  It was fixed 2 months ago.
> AFAIK snapshots and quotas are also broken in 5.x, so the remaining
> problem is not a regression.

It depends on the statement's scope. I was suggesting that there is a
regression in the overall scope of the "user experience" between a 4.x
and a 5.x or 6.x system, when using the default and recommended

> > This assumes that 6.1 absolutely must be released -- must it, in its
> > current state? The VFS code is indeed incredibly complicated, but it
> > is also absolutely critical. The server is completely useless if
> > filesystem operations fail. Would there really be harm in putting off
> > a release until these well-acknowledged bugs are taken care of?
> Yes, it ties up a lot of developer resources and causes the release
> engineers to burn out.
> As several key developers have already explained, if you adopt a
> policy of delaying the release until all serious bugs are fixed, there
> will be no more releases of FreeBSD ever again.  I assume you don't
> want that, which means that you have to draw a line somewhere.  The
> line has now been drawn.

I wouldn't dare suggest that all bugs must be fixed prior to a new
release, but I will suggest that releases could be delayed to fix
critical bugs that, under a completely stock and default installation:
stop the filesystem from functioning, report no errors to the user,
and require that the user hard-reset their computer. At the very
least, the defaults could be modified such that Joe Average User won't
be affected by it, and those that want cutting-edge features like
snapshots, background fscks, etc. can enable them. This should result
in fewer headaches for users and those that help them. Additionally,
the users that want these new features are likely those that are
already running -STABLE, so it's a lot easier and more practical for
them to try the latest incremental updates, as necessary.

You are right, I do want there to be new releases of FreeBSD. I'd just
prefer that the push for new releases be driven by improvements in
stability, and then features. Snapshots seem like they will be a great
feature, and themselves will improve overall system stability, but for
now they are not ready to be enabled by default. Adding features is
certainly more sexy than fixing bugs, and concentrating on nothing but
bugs can cause burnout (temporary or permanent), but a stable release
will benefit everyone -- developers and users -- by providing them
with a platform they can grow with.

More information about the freebsd-stable mailing list