From owner-svn-src-all@freebsd.org Thu Nov 16 15:27:46 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 54684DE11F4 for ; Thu, 16 Nov 2017 15:27:46 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (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 14F8D7EA6D for ; Thu, 16 Nov 2017 15:27:46 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x235.google.com with SMTP id 71so5599339ior.7 for ; Thu, 16 Nov 2017 07:27:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=t9jtwmyTprbi+k/iPeeB6OVOrHvrKRUIC+l6bkLzSfQ=; b=IwnNgC4OPot8a3botIAxs7zUFrML9sThuLZR9BKS7X+9HL91a1twSJz7lCGFDPCMce gT3JXE22FcQQW/N6aJXf/eUSRAzC5/RiK8tTKhmz8C/kcO0lj4Uh0weNPH44JCcOjW2U qDCPDKi0fBwlbwlQfEvIbOe9YN85gP1Z9/E6udrymiEZuWPypFRrCUxMGEHdmJAItqWH w7ajz3y7boNl8M+sIK+INFdCnNW92NViuvj0rybPgiWlU2/JNBNTsCYllCkTt+p8OJH8 8kTNQV+DPwOIcexzLUL17nPRSlaARRwO1qZ8DUiicnIcNoaxZItVC4gpUtyV6iFHyw0I lRwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=t9jtwmyTprbi+k/iPeeB6OVOrHvrKRUIC+l6bkLzSfQ=; b=ZaxbiD0I0lmtMjtYchYXO83pbJ1rzGv2BoVT6dkh8+Y8VVn0MmwX4lmFRDlzmyNu1+ P3t25ufEGLvooIQCDz+5v9AETFJQzbQ2+wa2XCRIPlGDsaPxqGt0fBbr3c53UN9y+XiA noyWsHbfaciv1TBnq22XS/m0Zfpkgsffbd8EYLPnAnLSzGWrfms7qBl4oYFZDV6WMUGE 1VoZrhKMoLq+dWh8ie3qShqsq7OZm5f/csIkXz7tFiYeL59Irr3C0IuWC6cuo1qCHfdk GAxFS2GbDKvuYerlcdby0OvQpCUZLlv2WHFidoF15sSIahA6pUgAxpSuNW74EsENaBrP Lrzw== X-Gm-Message-State: AJaThX6g5xJzKcqrMtcehNhG2sNxALUwDbIfHffDGme7Q3dsQmt9s7FY ZsmD44Ilu2+fohBMdvUSAQH6/7WlbQtocPwKpTmKLg== X-Google-Smtp-Source: AGs4zMavvfO96TiwwejITrNVLN2Tl8XM63Py22U+knPyn2Rsu7gyU6hQ00xqIU2Y75hGywQaCpGTaRYb2aozEmqFFPE= X-Received: by 10.107.52.80 with SMTP id b77mr2141513ioa.291.1510846063367; Thu, 16 Nov 2017 07:27:43 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Thu, 16 Nov 2017 07:27:42 -0800 (PST) X-Originating-IP: [63.225.28.164] In-Reply-To: <6247771.UqFN5CEdG4@ralph.baldwin.cx> References: <201711151840.vAFIefKV002185@repo.freebsd.org> <6247771.UqFN5CEdG4@ralph.baldwin.cx> From: Warner Losh Date: Thu, 16 Nov 2017 08:27:42 -0700 X-Google-Sender-Auth: u5PMRgrUKw-JD41l4ZdzFOxpCGw Message-ID: Subject: Re: svn commit: r325860 - head/sbin/newfs To: John Baldwin Cc: Ed Maste , "Rodney W. Grimes" , src-committers , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" , Kirk McKusick Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 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: Thu, 16 Nov 2017 15:27:46 -0000 On Wed, Nov 15, 2017 at 11:29 PM, John Baldwin wrote: > On Wednesday, November 15, 2017 10:17:27 PM Warner Losh wrote: > > On Wed, Nov 15, 2017 at 6:46 PM, Ed Maste wrote: > > > > > On 15 November 2017 at 19:36, Warner Losh wrote: > > > > > > > > On Wed, Nov 15, 2017 at 5:05 PM, Ed Maste > wrote: > > > >> > > > >> On 15 November 2017 at 13:47, Rodney W. Grimes > > > >> wrote: > > > >> >> Author: emaste > > > >> >> Date: Wed Nov 15 18:40:40 2017 > > > >> >> New Revision: 325860 > > > >> >> URL: https://svnweb.freebsd.org/changeset/base/325860 > > > >> >> > > > >> >> Log: > > > >> >> newfs: warn if newer than kernel > > > >> >> > > > >> >> Creating a UFS filesystem with a newfs newer than the running > > > kernel, > > > >> >> and then mounting that filesystem, can lead to interesting > > > failures. > > > >> >> > > > >> >> Add a safety belt to explicitly warn when newfs is newer than > the > > > >> >> running kernel. > > > >> > > > > >> > You should probably make the warning if (newer || older) as > > > >> > either is likely to have interesting side effects, as are > > > >> > mounting ufs file systems on different versions. > > > >> > > > >> Why would an older newfs cause trouble? Forward compatibility > should be > > > >> fine > > > > > > > > The only scenario that 'old' would cause problems is that if you did > a > > > newfs > > > > with a new binary on a new kernel, mounted the file system, wrote > files > > > to > > > > it, then rebooted with an old kernel, mounted the filesystem there, > > > writing > > > > new files to it, and then unmounting and running with a new kernel. > > > > > > Right, but that's not older newfs. AFAICT there's no reason at all for > > > a (newer || older) warning. > > > > > > I concur. > > > > > I'm not sure that the new safety belt is reasonable. Today it's fine, > but > > > > over time it will start producing false-positive warnings since the > real > > > > issue is just before/after the cg change, not old/new in general. > I'd be > > > > tempted to make a check against newfs being >= 1200046 while the > kernel > > > is < > > > > 1200046. There wasn't a specific bump for this change to > sys/param.h, but > > > > this version was bumped within a few hours of Kirk's change. > > > > > > Well, we don't in general support using a userland newer than the > > > running kernel, other than on a best-effort basis to facilitate > > > upgrades and development. This one is only a warning so I don't see > > > much harm in leaving it in place, and it would catch any new cases of > > > a similar nature. If such a warning was already in place we might have > > > avoided the issue where our snapshots produced checksum mismatch > > > messages. But I don't have a strong objection to a hardcoded version > > > check. > > > > > > > What would have fixed the snapshot isn't a warning that nobody will > notice. > > But rather something like the following: > > No, what would really fix the snapshot is using makefs or the host newfs > instead of the target newfs during the build. That part of the release > process is still fundamentally broken and fixing that wouldn't require > various > one-off fixes for future changes that happen to introduce compatability but > would fix the entire class of issues. > I agree with that. However, more than just FreeBSD's release process uses the newly built tools to do things, so those tools shouldn't do dangerous things when it's trivial to know not to. They are orthogonal issues, imho. Netflix's upgrade process, for example, uses the new newfs on an old kernel, mounts the filesystem and then splats new content into the filesystem. The issue is larger than our somewhat imperfect (but working) release building process. Warmer