From owner-freebsd-questions@freebsd.org Tue Apr 21 15:58:33 2020 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 45B772A9FC4 for ; Tue, 21 Apr 2020 15:58:33 +0000 (UTC) (envelope-from freebsd-lists-5@thismonkey.com) Received: from mail-01.thismonkey.com (mail-01.thismonkey.com [IPv6:2406:3400:35e:6602::a01:232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thismonkey.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4967X54Szdz4VrW for ; Tue, 21 Apr 2020 15:58:28 +0000 (UTC) (envelope-from freebsd-lists-5@thismonkey.com) X-TM-Via-MX: mail-01.thismonkey.com Received: from utility-01.thismonkey.com (utility-01.thismonkey.com [IPv6:2406:3400:35e:6601:0:0:a01:120]) by mail-01.thismonkey.com (8.15.2/8.15.2) with ESMTPS id 03LFwDtm061526 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 22 Apr 2020 01:58:15 +1000 (EST) (envelope-from freebsd-lists-5@thismonkey.com) Received: from utility-01.thismonkey.com (localhost [127.0.0.1]) by utility-01.thismonkey.com (8.15.2/8.15.2) with ESMTP id 03LFwDYb002107; Wed, 22 Apr 2020 01:58:13 +1000 (EST) (envelope-from freebsd-lists-5@thismonkey.com) Received: (from root@localhost) by utility-01.thismonkey.com (8.15.2/8.15.2/Submit) id 03LFwC6f002017; Wed, 22 Apr 2020 01:58:12 +1000 (EST) (envelope-from freebsd-lists-5@thismonkey.com) Date: Wed, 22 Apr 2020 01:58:12 +1000 From: Scott To: Polytropon , freebsd-questions@freebsd.org Subject: Re: Should fsck honour "failok" in fstab as mount does? Message-ID: <20200421155812.GA54069@thismonkey.com> Mail-Followup-To: Polytropon , freebsd-questions@freebsd.org References: <20200421071319.GA98163@thismonkey.com> <20200421153144.d45a889b.freebsd@edvax.de> <20200421135406.GA74559@thismonkey.com> <20200421160939.aa2fbd89.freebsd@edvax.de> <20200421143321.GA33168@thismonkey.com> <20200421170313.16d4235e.freebsd@edvax.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200421170313.16d4235e.freebsd@edvax.de> User-Agent: Mutt/1.11.4 (2019-03-13) X-Virus-Scanned: clamav-milter 0.102.2 at mail-01.thismonkey.com X-Virus-Status: Clean X-Rspamd-Queue-Id: 4967X54Szdz4VrW X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=thismonkey.com; spf=pass (mx1.freebsd.org: domain of freebsd-lists-5@thismonkey.com designates 2406:3400:35e:6602::a01:232 as permitted sender) smtp.mailfrom=freebsd-lists-5@thismonkey.com X-Spamd-Result: default: False [-3.51 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[thismonkey.com,none]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:10143, ipnet:2406:3400:300::/40, country:AU]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(-1.71)[ip: (-7.59), ipnet: 2406:3400:300::/40(-3.79), asn: 10143(2.84), country: AU(0.01)] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 15:58:33 -0000 On Tue, Apr 21, 2020 at 05:03:13PM +0200, Polytropon wrote: > On Wed, 22 Apr 2020 00:33:21 +1000, Scott wrote: > > Yes but I DO want fsck to look at the filesystem, but continue if it > > fails (for example, if the device does not exist). Just like I DO want > > mount to mount the filesystem, but continue if it can't. > > That is not the purpose of /etc/fstab, I'd think. As per the > manual, there is a certain requirement for filesystems that > do not have the "noauto" option specified. Well no, see the next reply. > > > That's not completely true, because for NFS mounts we have the `bg' > > option, which allows the system to continue booting even if it can't be > > mounted. i.e.: not all `noauto' filesystems are _required_. > > They are required, it's just that their mount process is sent > to the background and can happen later on. :-) > > I think the main difference here is that NFS mounts are not > subject to a previous fsck success. The core problem here is > that local filesystems will be checked before a mount attempt > can happen (and fail). NFS mounts ARE NOT required for boot to complete if the `bg' option is set. mount_nfs just forks off and remains so forked unless the mount completes. My point is an absence of `noauto' does not mean a filesystem MUST mount or the system drops into single user. > > > I think you're expecting "failok" to do something it is not > > > intended to do. > > > > > > > Not really. I want `failok' to do something it doesn't currently. Where > > would be the harm in patching fsck to recognise it? > > No harm, it would surely be possible. It would in fact combine > two things (imaginary "nofsck" followed by "failok"). So what > you expect "failok" ("two in one") to is: > > if filesystem does exist: > perform fsck > if fsck successful: > mount filesystem > if ! mount successful > do nothing <--- SUM (2) > else > do nothing <--- SUM (1) > else > do nothing > > The arrows indicate points where currently the system boot > process would be interrupted in case of an error. Of course > the order is not intuitive here (error branch should come > first). Yes. And the `failok' option modifies SUM (2). I'm not sure I would have `nofsck', rather `fsckfailok' such that fsck is run if possible (in preparation for a mount) but booting can continue if not. > > Given the resistance perhaps I should be pushing for fsck to continue on > > a non-existent device (really, how does a missing device fail a > > consistency check?). Then mount will presumably fail if the `failok' is > > not present. > > If the "noauto" option is not present, and the device for > the filesystem does not exist, the boot process will be > interrupted - sure, no fsck, no mount. The "failok" option > could be used for the purpose mentioned above. fsck does seem to have an errorlevel (3) for devices it can't stat, so maybe this condition could be pushed to /etc/rc.d/fsck. > As fsck will read /etc/fstab, the "failok" option could be > considered, or a new "nofsck" option could be introduced. > Currently it is of no importance for fsck, as only the > device name, the filesystem type, and the 6th column matter. That's not entirely accurate: fsck also checks fs_mntops: if (!strncmp(&fs->fs_mntops[i], "noauto", 6)) > Don't get me wrong, I'm not against this idea. The question > is just if "failok" should _imply_ a different fsck and > mount behaviour. Agreed. The terminology should be either `failok' for all failures regardless of the program (fstab (5) does mention it is used by both fsck and mount), or split into `mountfailok` and `fsckfailok`. Scott