From owner-svn-src-all@freebsd.org Tue Jul 11 20:35:24 2017 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ECC6EDABB36 for ; Tue, 11 Jul 2017 20:35:24 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CF22567145 for ; Tue, 11 Jul 2017 20:35:24 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 7624ea03-6678-11e7-bfd0-afd4446ba3af X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id 7624ea03-6678-11e7-bfd0-afd4446ba3af; Tue, 11 Jul 2017 20:35:22 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v6BKZFUD044104; Tue, 11 Jul 2017 14:35:15 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1499805315.45330.14.camel@freebsd.org> Subject: Re: svn commit: r320803 - head/sbin/mount From: Ian Lepore To: Edward Tomasz Napierala , rgrimes@freebsd.org Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Date: Tue, 11 Jul 2017 14:35:15 -0600 In-Reply-To: <20170711201230.GB1725@brick> References: <20170708171641.GA1129@brick> <201707081734.v68HYpN9068500@pdx.rh.CN85.dnsmgr.net> <20170711201230.GB1725@brick> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.23 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: Tue, 11 Jul 2017 20:35:25 -0000 On Tue, 2017-07-11 at 21:12 +0100, Edward Tomasz Napierala wrote: > On 0708T1034, Rodney W. Grimes wrote: > > > > [ Charset ISO-8859-1 unsupported, converting... ] > > > > > > On 0708T1102, Ian Lepore wrote: > > > > > > > > On Sat, 2017-07-08 at 09:50 -0700, Rodney W. Grimes wrote: > > > > > > > > > > [ Charset UTF-8 unsupported, converting... ] > > > > > > > > > > > > > > > > > > Author: trasz > > > > > > Date: Sat Jul??8 11:06:27 2017 > > > > > > New Revision: 320803 > > > > > > URL: https://svnweb.freebsd.org/changeset/base/320803 > > > > > > > > > > > > Log: > > > > > > ? Fix "mount -uw /" when the filesystem type doesn't match. > > > > > > ?? > > > > > > ? This basically makes "mount -uw /" work when the > > > > > > filesystem > > > > > > ? mounted on / is NFS, but the one configured in fstab(5) > > > > > > is UFS, > > > > > > ? which can happen when you forget to modify fstab. > > > > > Please do not silence user errors because they are > > > > > inconvinient, > > > > > this is a configuration error and the system should fail to? > > > > > mount the incorrectly configured root. > > > > > > > > > > If we start changing things to silently ignore user > > > > > configuration > > > > > errors we are going down a very slippery road. > > > It doesn't silence down the error.  What it does is it makes it > > > possible > > > to use "mount -uw /" - previously it would fail in a rather > > > nonsensical > > > way, by calling "mount_nfs -o upgrade,rw /dev/ada0 /". > > It DOES silence the error.  My configuration TOLD it to execute > > that > > rather nonsensical command, your change now causes it to execute > > something > > that my configuration did NOT tell it to do. > I don't know your configuration; mine certainly didn't tell it to try > to > mount /dev/ada0 as NFS.  What I certainly _did_ told it was to "mount > -uw /", > and previously, in some cases, it failed to do this.  Now it works. > > From a practical standpoint, it's like this: I have an NFS root > filesystem > mounted read-only.  There's a slightly wrong fstab.  I want to > remount it > read-write and fix it.  With UFS I can.  I expect the same with NFS. > > > > > > > > > > > > > > IMO, this change fixes the right problem, but maybe does so the > > > > wrong > > > > way. ?Mount -u is by definition an update to an existing mount. > > > > ?There > > > > should be no need to consult /etc/fstab for an existing mount > > > > since the > > > > info is available from the kernel. > > > > > > > > Note that I say the foregoing with my user hat on. ?I haven't > > > > looked at > > > > the code to see if there's some reason why my common-sensical > > > > way of > > > > thinking about it is actually impossible to implement for some > > > > reason. > > > I wouldn't expect it to consult fstab either, to be honest.  But > > > it does, > > > and I suspect changing that would break someone's config. > > It reads the fstab to get the options that may be specified there > > that your mount -uw / command does not specify, realize the kernel > > when mounting / does so in a very minimal way, when you invoke > > mount -u the parameters in /etc/fstab come in to play. > Yup, that's it.  So it is right in most cases - it's just that the > hack > for "/" case sometimes worked in an way that's pretty obviously wrong > (using the fstab value for "mounted from", but ignoring the > filesystem > type), although didn't hurt before reroot, because it could never > happen. > > > > > I believe KIB refered to this during your differential when he said > > something like "what if the options disagree". > Possibly. I think the docs on this are pretty clear... under -u it says: The set of options is determined by applying the options specified in the argument to -o and finally applying the -r or -w option. To me, that says that nothing in /etc/fstab is germane to mount -u unless one of the other args to mount -u is -o fstab. This change (r320803) seems like an acceptable workaround, but I think the correct long term fix would be to not even open /etc/fstab on mount -u without -o fstab.  But that may be harder to do than to say; I still haven't actually looked at the code involved. -- Ian