Date: Mon, 6 Nov 2017 01:46:49 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Konstantin Belousov <kostikbel@gmail.com> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r324853 - in head/sys: kern sys Message-ID: <20171106010605.L1257@besplex.bde.org> In-Reply-To: <20171105130349.GZ2566@kib.kiev.ua> References: <201710220811.v9M8Bjw5033551@repo.freebsd.org> <20171105014453.L1354@besplex.bde.org> <20171105130349.GZ2566@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 5 Nov 2017, Konstantin Belousov wrote: > On Sun, Nov 05, 2017 at 03:06:22AM +1100, Bruce Evans wrote: >> On Sun, 22 Oct 2017, Konstantin Belousov wrote: >> >>> Author: kib >>> Date: Sun Oct 22 08:11:45 2017 >>> New Revision: 324853 >>> URL: https://svnweb.freebsd.org/changeset/base/324853 >>> >>> Log: >>> Remove the support for mknod(S_IFMT), which created dummy vnodes with >>> VBAD type. >>> >>> FFS ffs_write() VOP catches such vnodes and panics, other VOPs do not >>> check for the type and their behaviour is really undefined. The >>> comment claims that this support was done for 'badsect' to flag bad >>> sectors, we do not have such facility in kernel anyway. >> >> badsect(8) is a utility and this commit breaks it by removing its kernel >> support. > > I see, thank you for the pointer. I will prepare the patch to remove > badsect(8). That would increase the number of things to fix. Even if badsect(8) is implemented less hackishly, binary compatibility for mknod(2) requires ifdefing it with COMPAT_*. I only checked that badsect(*) worked before this commit without INVARIANTS or soft updates. Perhaps the panic always occurs with INVARIANTS due to some INAVRIANTS check being wrong, or soft updates doesn't understand this case. badsect(8) says to run badsect on a "quiet" file system, but this should only be necessary to prevent the bad block being reallocated while you are creating a VBAD file to hold it. Note that mknod(S_IFMT) doesn't force an fsck before the next mount. This seems to be be just another bug involving the clean flag -- I doubt that it is really safe to never clean up the VBAD files, so creating one should have set a sticky dirty flag. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20171106010605.L1257>