Date: Mon, 6 Nov 2017 05:26:27 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Bruce Evans <brde@optusnet.com.au>, 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: <20171106030252.W1814@besplex.bde.org> In-Reply-To: <20171105153026.GC2566@kib.kiev.ua> References: <201710220811.v9M8Bjw5033551@repo.freebsd.org> <20171105014453.L1354@besplex.bde.org> <20171105130349.GZ2566@kib.kiev.ua> <20171106010605.L1257@besplex.bde.org> <20171105153026.GC2566@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 5 Nov 2017, Konstantin Belousov wrote: > On Mon, Nov 06, 2017 at 01:46:49AM +1100, Bruce Evans wrote: >> 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. > In which way ? It requires unremoving badsect(8) as well as its kernel support. >> Even if badsect(8) is implemented less hackishly, binary compatibility >> for mknod(2) requires ifdefing it with COMPAT_*. > No, mknod(S_IFMT) is clearly non-functional management interface, and we > allow management interface changes between releases, and if desired, inside > the releases as well. No, it was perfectly functional. Much more than in 4.1BSD. Then it was limited to 16-bit block numbers by dev_t being 16 bits. With a block size of 512, that limited it to file systems of size 32 MB. That wasn't enough for a small University system in 1981, and Berkeley isn't small. It was far too small for FreeBSD-1 in 1993. 32-bit dev_t in 4.4BSD and FreeBSD-2 was large enough until relatively recently. It is larger than signed 32-bit daddr_t and ufs1_daddr_t. Now 64-bit dev_t is larger than signed 64-bit daddr_t and ufs2_daddr_t. BTW, I'm now fixing dev_t for newnfs. I fixed oldnfs to catch up with 32-bit dev_t in 1996, but newfs for v3 still hard-codes for 16-bit dev_t (actually for 8-bit major() and minor()), and ABI breakage loses all bits in major() for v3 and v4 when the kernel uses the new ABI and applications use the old ABI. v2 actually works better using raw dev_t's if the server and client application use the same 32-bit encoding. >> 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. > UFS code is not prepared to VBAD vnodes. I do not mean specifically the > vnode type, but the VOPs operations on such inodes. But it is prepared when used as documented in badsect(8). > It is pointless to spend the time on making it functional. Modern disk > failure modes made badsect(8) useless in the beginning if the beginning > of 199x. It is just too hard to use without a more complicated program to control it. I used a "modern" disk's remapping to fix a few thousand bad sectors which needed to be fixed or zeroed just to copy as much as possible before replacing the disk, but the spares ran out too soon. bad144 would have worked better. IIRC, it can handle 64K remaps. badsect was too hard to use to even try for a few thousand not even transparent remaps. > I will commit the following patch after make universe finishes. I don't like this. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20171106030252.W1814>