Remove some hackish intentional 64->32 truncations next to the checks
using LFS_MAX_DADDR, and tackle the problem they handled in bmap
instead.
The problem: the magic block pointer value UNWRITTEN has magic value
-2, and if it's not handled specifically, uint32 -> uint64 promotion
turns it into 4294967294, which then causes consternation and
monkeyhouse downstream.
What's here is still kind of a hack, but it's a step forward.
Add pieces of support for using both superblock types where
convenient, and specifically to the superblock accessors, but don't
actually enable it anywhere.
First substantive step on PR 50000.
(lfs_curseg/lfs_nextseg in the superblock) using the wrong units.
These fields are for whatever reason the start addresses of segments
(measured in frags) rather than the segment numbers 0..n.
This only apparently affects dumping from a mounted fs; however, it
trashes the fs.
I would really, really like to have a static analysis tool that can
keep track of the units things are measured in, since fs code is full
of conversion macros and the macros are named inscrutable things like
"sntod" whose letters don't necessarily even correspond to the units
they convert. It is surprising that more of these are not wrong.
in blocks instead of frags, so use lfs_blkstofrags to correct it.
This code was instead multiplying by the block size divided by
DEV_BSIZE to get the number of disk blocks rather than the number of
frags. (I gather that originally these were the same, but they're not
necessarily any more.)
VFS_SYNC does not consider whether we are performing a force unmount or not,
and therefore it can wait for a while if the filesytstem is misbehaving.
Removing VFS_SYNC before VFS_UNMOUNT on forced unmount fixes the problem.
This should not cause harm as the VFS_SYNC seems just useless.
As noted by Chuck Silvers in
http://mail-index.netbsd.org/tech-kern/2015/07/13/msg019156.html
- Nothing seems to prevent vnodes from getting dirty again after VFS_SYNC call.
- Filesystems do flush data through vflush() in VFS_UNMOUNT anyway.
As a consequence, the VFS_SYNC call in do_unmount() could probably be
completely removed. But since such a change is quite dangerous, we just
remove it in the case of forced unmounts, which are situations where
the risk of data loss is known to the operator.
