On 15 November 2017 at 19:36, Warner Losh <i...@bsdimp.com> wrote: > > On Wed, Nov 15, 2017 at 5:05 PM, Ed Maste <ema...@freebsd.org> wrote: >> >> On 15 November 2017 at 13:47, Rodney W. Grimes >> <free...@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.
Right, but that's not older newfs. AFAICT there's no reason at all for a (newer || older) warning. > 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. _______________________________________________ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"