Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 15 Nov 2017 17:36:22 -0700
From:      Warner Losh <imp@bsdimp.com>
To:        Ed Maste <emaste@freebsd.org>
Cc:        "Rodney W. Grimes" <rgrimes@freebsd.org>, src-committers <src-committers@freebsd.org>,  "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>,  "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>
Subject:   Re: svn commit: r325860 - head/sbin/newfs
Message-ID:  <CANCZdfpN3Q68rxcGn75BCUwv47__=5p_=N%2BPpoqqQbnJTOb8zw@mail.gmail.com>
In-Reply-To: <CAPyFy2BMDoA%2Bs76ddyNBYo1iC7TZq99_MNZi%2BmHFV6iAgQxgbQ@mail.gmail.com>
References:  <201711151840.vAFIefKV002185@repo.freebsd.org> <201711151847.vAFIlGD9052509@pdx.rh.CN85.dnsmgr.net> <CAPyFy2BMDoA%2Bs76ddyNBYo1iC7TZq99_MNZi%2BmHFV6iAgQxgbQ@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Nov 15, 2017 at 5:05 PM, Ed Maste <emaste@freebsd.org> wrote:

> On 15 November 2017 at 13:47, Rodney W. Grimes
> <freebsd@pdx.rh.cn85.dnsmgr.net> 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. At that point, the new kernel will start printing cg mismatch
errors and will limit its allocation to CGs that weren't modified when it
was mounted under the old kernel (since those CGs will have changed their
checksum, but no new checksum will have been computed). The root cause here
is that the old kernel doesn't know that the CK_CYLGRP tags the cg as
having the proper hash metadata associated with them.

It sounds like this is exactly what Rod does on a regular basis as he's
taking a disk from one system to another and back again, maybe for file
transport on a USB stick. It's not a crazy scenario. At this point, there's
the annoyance of the messages, but that will be fixed with an fsck.

The scenario where I have a newer kernel and an old newfs will be a nop:
the old newfs won't set CK_CYLGRP, so the kernel won't checksum, so there
won't be any mismatch possible.

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.

Warner



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfpN3Q68rxcGn75BCUwv47__=5p_=N%2BPpoqqQbnJTOb8zw>