From owner-svn-src-head@freebsd.org Tue Jul 11 20:12:35 2017 Return-Path: Delivered-To: svn-src-head@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 5652FDAB66B; Tue, 11 Jul 2017 20:12:35 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (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 EE8BE656DE; Tue, 11 Jul 2017 20:12:34 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by mail-wr0-x231.google.com with SMTP id k67so4167449wrc.2; Tue, 11 Jul 2017 13:12:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=6JQKWRoaFiS2Froyox2oo022VPU0hB8qOfJIvqDfmRg=; b=WZa5yuB+RW2nK/DpzEFyKRcjaYEBt2BPQ7J334Z61DKFtuIFdS+w/JHdNKNZ9NuAgj sXtjG2zPjgors7yCmPO/ym7bDLiFWHOyfGz2w23MpJgoF1mZvTfznnDw3AgQ6z6tqh3g MAjEOejQwRD8EV2KqNpSs+/iwLkcsN8UdPoCzABRks9yXvx5IeIZFI1XffP67cEPtro1 EgLyBjU8YW3nqFmXFXrPILyEvHuU2OU/fhdq5ta4zWfe8BWuTMzr89VCQEUeGUTehCXR RAZ5VqRydzwVVnuzIZfwcAudKwyok2QBW5/rnejI+j0LZA8ukkxAuIZYj7n9cufAXoIS KlWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=6JQKWRoaFiS2Froyox2oo022VPU0hB8qOfJIvqDfmRg=; b=dglKGKsRTLyPPaDrknqSRTpK0eG6wmENBo28YeUEE3Co3NyfMMt/mfnQRqjXZhdO2M z0knAOEDFvNXLOFFQDVG7SdCXD9I/3L+P1WEf857WuvNNVcRlC5v03KUfNOfPxx+AQ2p /N36HD30ZzgUT+iyIyAiv+wv26TRsMOwaD88i3OQmze7BoeXLGlAN+fIGhSZhdJtOLku PGSiI+GGa1GAZC6LXM4a4Q0g/2d9MLKWcAq1Uw5p43vOi5boKRhWtu1GCyPAH+WfsW4h IOQgLNqcuZbEi/Q65I5psqBgFXPKcDmN+q3EVtHHhqQTNNkwKCSQWsnFG0oNtQJdCiWs ukZg== X-Gm-Message-State: AIVw113Gi6aFKPFfV0jilxFtixbouDFK9VNskDwURK93IUm7oZcjHjhH 4NDJCwG/SG2Ts6rK X-Received: by 10.223.154.206 with SMTP id a72mr933541wrc.47.1499803952982; Tue, 11 Jul 2017 13:12:32 -0700 (PDT) Received: from brick (cpc92310-cmbg19-2-0-cust934.5-4.cable.virginm.net. [82.9.227.167]) by smtp.gmail.com with ESMTPSA id k75sm261991wmh.10.2017.07.11.13.12.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Jul 2017 13:12:32 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Tue, 11 Jul 2017 21:12:30 +0100 From: Edward Tomasz Napierala To: rgrimes@freebsd.org Cc: Ian Lepore , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r320803 - head/sbin/mount Message-ID: <20170711201230.GB1725@brick> Mail-Followup-To: rgrimes@freebsd.org, Ian Lepore , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org References: <20170708171641.GA1129@brick> <201707081734.v68HYpN9068500@pdx.rh.CN85.dnsmgr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201707081734.v68HYpN9068500@pdx.rh.CN85.dnsmgr.net> User-Agent: Mutt/1.8.2 (2017-04-18) X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 20:12:35 -0000 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.