Any -current kernel built over the weekend is a likely victim of this bug.
In a nutshell, it will eat your root filesystem at the very least, leaving
you with maybe one or two files in /lost+found. spec_vnops.c rev 1.156
is should be avoided at all costs.
BEWARE: there are some snapshots on current.freebsd.org with this bug. They
will self destruct after install.
------- Forwarded Messages
phk 2001/04/29 04:48:42 PDT
Modified files:
...[other files in commit trimmed]
sys/miscfs/specfs spec_vnops.c
Log:
Add a vop_stdbmap(), and make it part of the default vop vector.
Make 7 filesystems which don't really know about VOP_BMAP rely
on the default vector, rather than more or less complete local
vop_nopbmap() implementations.
Revision Changes Path
1.156 +1 -2 src/sys/miscfs/specfs/spec_vnops.c
------- Message 2
bde 2001/04/30 07:35:37 PDT
Modified files:
sys/miscfs/specfs spec_vnops.c
Log:
Backed out previous commit. It cause massive filesystem corruption,
not to mention a compile-time warning about the critical function
becoming unused, by replacing spec_bmap() with vop_stdbmap().
ntfs seems to have the same bug.
The factor for converting specfs block numbers to physical block
numbers is 1, but vop_stdbmap() uses the bogus factor
btodb(ap->a_vp->v_mount->mnt_stat.f_iosize), which is 16 for ffs with
the default block size of 8K. This factor is bogus even for vop_stdbmap()
-- the correct factor is related to the filesystem blocksize which is not
necessarily the same to the optimal i/o size. vop_stdbmap() was apparently
cloned from nfs where these sizes happen to be the same.
There may also be a problem with a_vp->v_mount being null. spec_bmap()
still checks for this, but I think the checks in specfs are dead code
which used to support block devices.
Revision Changes Path
1.157 +2 -1 src/sys/miscfs/specfs/spec_vnops.c
------- End of Forwarded Messages
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message