From owner-svn-src-all@freebsd.org Sat Mar 10 07:29:16 2018 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 12FC3F2B15D for ; Sat, 10 Mar 2018 07:29:16 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-yw0-x241.google.com (mail-yw0-x241.google.com [IPv6:2607:f8b0:4002:c05::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A73B887BE3 for ; Sat, 10 Mar 2018 07:29:15 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: by mail-yw0-x241.google.com with SMTP id l24so2389218ywk.6 for ; Fri, 09 Mar 2018 23:29:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=RX5LswTUFS0Mlz9dkyYI6Krmb9Fm6KJG9nCJ2C+0GHY=; b=GT8jMs6VsqzRyhGPIPBMxyi9MTe+LpmKHIPTdqEvJDkahaR/+pE/wwXlsqC4N/EkPc oFlFR/fYS2WRu+nO29t11qpE+YxYjahhFPnpU5lkPhsyyoOLfexdFFBqXQIBsX/6gi6j 5slJAfn5fnwfE7uya07HwDMItv0bpzCDfzgjU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=RX5LswTUFS0Mlz9dkyYI6Krmb9Fm6KJG9nCJ2C+0GHY=; b=PBsAIOKlb+cq+SyDfKA1gQV9ijJ+0ADsF2MIJwC6XG3EKcOikzYbKJCD+/EFPonRPr LEk6+5X/xxXabYPosf9Nn6nqvJ36Jywa54EVS3vzkEDMWi+bNt+yfHkSY/sfvEu9pL+0 TZasbE8XjWB5WZ8bJwG0JNPh5lT/ppQ52PoNi71Gcmaf8WKNkhWRFYG7d/LMIxv7zoKf CEpr642LoH6YDE0GF5fQIfSXVQA9uephP2kMdpebFkzzd6ndFQNFGHq38i2kfq+wBFN+ f5qM16tBq9M2y0kr/OdXZC/jIyaaM2Sz7bTmYcANZVtChpnXI9y8mweMDVZkMdTvyVds b/Yw== X-Gm-Message-State: AElRT7EBMur/oC6lQ5bgbdeUXBk/CrXzFqwhtHgU1aU/2Us8i5fDuZ8K CpskFEObspTpIRjPl0LXFWEPrsTfI9WrPhJngEvKiA== X-Google-Smtp-Source: AG47ELtUyZYQL5ayceQGDcOa3+aHY2Nujf2J9Bv1liw2krAQdv/sEpMVRJSdNwUm8VxHo+L6ZaQWT+xTn9/uME+R874= X-Received: by 2002:a25:accd:: with SMTP id x13-v6mr622490ybd.194.1520666954752; Fri, 09 Mar 2018 23:29:14 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a25:23d2:0:0:0:0:0 with HTTP; Fri, 9 Mar 2018 23:28:44 -0800 (PST) In-Reply-To: References: <201801151925.w0FJPCKA019434@repo.freebsd.org> <20180309220940.GG6174@raichu> <1520634689.84937.74.camel@freebsd.org> From: Eitan Adler Date: Fri, 9 Mar 2018 23:28:44 -0800 Message-ID: Subject: Re: svn commit: r328013 - head/sbin/fsck_ffs To: David Bright Cc: Ian Lepore , Mark Johnston , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2018 07:29:16 -0000 On 9 March 2018 at 18:36, David Bright wrote: > On Mar 9, 2018, at 17:31, Ian Lepore wrote: >> >> On Fri, 2018-03-09 at 17:09 -0500, Mark Johnston wrote: >>> >>> etc/rc.d/fsck doesn't know how to interpret the new exit code and now >>> just drops to a single-user shell when it is encountered. [=E2=80=A6] >>> >>> Is there any reason etc/rc.d/fsck shouldn't automatically retry (up to > > This is, in fact, the reason that I made the change I did. I was trying t= o put in a retry loop to rc.d/fsck, but found that I couldn=E2=80=99t get i= t to work because fsck and fsck_ffs were not exiting with non-zero status. = The drop to single user is not really due to the specific (new) error code = of 16, it is due to the fact that fsck_ffs is now exiting with a non-zero s= tatus when it hasn=E2=80=99t completely cleaned the file system; /any/ non-= zero status would cause the current rc.d/fsck script to go to single user. = Prior to my change, fsck_ffs was exiting with a zero status even though it = had not completely cleaned the filesystem and told the user to run it again= . > >> >> fsck_ffs already has a -R flag to automatically retry, wouldn't that be >> a better mechanism for handling this new type of retry? > > That=E2=80=99s true; however, there is currently no way to pass that flag= through the filesystem-agnostic fsck wrapper called from rc.d/fsck to the = filesystem-specific fsck_ffs program that it calls. One could implement a s= imilar flag on the fsck wrapper to be passed along to the filesystem-specif= ic checker, but I think fsck_ffs is the only one that currently implements = such a flag. Why does it need to be filesystem specific? Can't the retry happen in the wrapper itself? --=20 Eitan Adler