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
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "[email protected]"
