From owner-freebsd-stable@FreeBSD.ORG Thu May 4 01:28:38 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1AD9F16A400 for ; Thu, 4 May 2006 01:28:38 +0000 (UTC) (envelope-from dpkirchner@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B9E243D46 for ; Thu, 4 May 2006 01:28:37 +0000 (GMT) (envelope-from dpkirchner@gmail.com) Received: by ug-out-1314.google.com with SMTP id e2so154898ugf for ; Wed, 03 May 2006 18:28:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=lG/5GZMUXiTqJBS3EnBiUiDNSikK+PeMWkQ7aTqkRu0jY9b5sRBIIGqSAZQKElcijQ6BH6CUqOrveFO/dEDdNYW4V9ElXFaSbPLF27BI7jmg08sUpRcoC+Cfn8bjfPbOWoZUWoCfD1ASlIqB1xRtyRVJD4WXIt1zuykskxgdvDk= Received: by 10.78.20.13 with SMTP id 13mr18463hut; Wed, 03 May 2006 18:21:39 -0700 (PDT) Received: by 10.78.13.2 with HTTP; Wed, 3 May 2006 18:21:39 -0700 (PDT) Message-ID: <35c231bf0605031821s582b6d03j3ee9d434a596f62a@mail.gmail.com> Date: Wed, 3 May 2006 18:21:39 -0700 From: "David Kirchner" Sender: dpkirchner@gmail.com To: "Robert Watson" In-Reply-To: <20060503110503.O58458@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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> X-Google-Sender-Auth: e80b3874e052cb11 Cc: stable@freebsd.org Subject: Re: quota deadlock on 6.1-RC1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2006 01:28:38 -0000 On 5/3/06, Robert Watson wrote: > This means that > they will take a significant amount of time to fix, and that each fix is = high > risk, as it is likely to reveal latent bugs. This means that each fix wi= ll > require a lot of testing -- months of testing, in fact. So the choice is > really, do we release 6.1, or do we skip it and do a 6.2 in a few months.= As > the release engineer, Scott has concluded that releasing now offers a gre= at > benefit to many people, although the bugs present may penalize some. Mind > you, in some cases the bugs also exist in 6.0, so they don't represent > regressions, so much as bugs that continue to persist. 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. In fact, it seems that enabling snapshots by default appears to have caused a significant regression for quotas and fsck operations (not for 'dump' however, since the default is to not use them). The workaround is for the user to disable all software that makes use of the feature, but the default settings released to users leaves them enabled and thus implicitly recommended.* I don't understand the need to issue a new release according to a strict schedule if it means leaving critical bugs that affect a fundamental feature of the OS: the filesystem itself. I think one would be well justified in delaying a new release in order to fix a bug in a subsystem of this magnitude. I may be applying my own personal beliefs here, but looking over the 6.1-RC2 RELNOTES.TXT file, I don't see any fixes or updates listed that are more important than general filesystem availability. > I agree with his > conclusion: things like locking interactions in VFS are incredibly > complicated, requiring extensive analysis and work to fix and test. Tryi= ng to > fix them for 6.1 is unrealistic. They can be fixed in the next few weeks= , > tested for a month or two, and then merged to the RELENG_6_1 branch as er= rata > fixes, similar to security advisories. 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? * rc.conf still has background_fsck enabled in version 1.282, and newfs.c still creates .snap by default in version 1.80 .