Date: Wed, 3 May 2006 20:05:12 -0700 From: "David Kirchner" <dpk@dpk.net> To: "Kris Kennaway" <kris@obsecurity.org> Cc: stable@freebsd.org, Robert Watson <rwatson@freebsd.org> Subject: Re: quota deadlock on 6.1-RC1 Message-ID: <35c231bf0605032005n4fe38769v9637a9393efb791a@mail.gmail.com> In-Reply-To: <20060504014241.GA38346@xor.obsecurity.org> References: <20060502171853.GG753@dimma.mow.oilspace.com> <20060502172225.GA90840@xor.obsecurity.org> <20060502174429.GH753@dimma.mow.oilspace.com> <44579EE1.6010300@rogers.com> <20060502180557.GA91762@xor.obsecurity.org> <4457A02C.9040408@rogers.com> <20060502182302.GA92027@xor.obsecurity.org> <20060503110503.O58458@fledge.watson.org> <35c231bf0605031821s582b6d03j3ee9d434a596f62a@mail.gmail.com> <20060504014241.GA38346@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 5/3/06, Kris Kennaway <kris@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 options. > > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?35c231bf0605032005n4fe38769v9637a9393efb791a>