all have zero length. A non-zero length panic's the kernel when one
of these is deleted.
PR: 19426
Submitted by: Ian Dowse <iedowse@maths.tcd.ie>
Reviewed by: dwmalone@FreeBSD.org
effect on operation of fsck on filesystems without snapshots.
If you get compilation errors, be sure that you have copies of
/usr/include/sys/mount.h (1.94), /usr/include/sys/stat.h (1.21),
and /usr/include/ufs/ffs/fs.h (1.16) as of July 4, 2000 or later.
DIR I=64512 CONNECTED. PARENT WAS I=4032
fsck: cannot find inode 995904
fsdb found the inodes with no problem:
fsdb (inum: 64512)> inode 995904
current inode: directory
I=995904 MODE=40777 SIZE=512
MTIME=Feb 14 15:27:07 2000 [0 nsec]
CTIME=Feb 14 15:27:07 2000 [0 nsec]
ATIME=Feb 24 10:31:58 2000 [0 nsec]
OWNER=nobody GRP=nobody LINKCNT=4 FLAGS=0 BLKCNT=2 GEN=38a41386
Direct blocks: 8094568 0 0 0 0 0 0 0 0 0 0 0
Indirect blocks: 0 0 0
The problem turns out to be a program logic error in fsck. It stores
directory inodes internally in hash lists, using the number of
directories to form the hash key:
inpp = &inphead[inumber % numdirs];
Elsewhere, however, it increments numdirs when it finds unattached
directories. I've made the following fix, which solved the problem in
the case in hand.
Submitted by: Greg Lehey <grog@lemis.com>
Reviewed by: Matthew Dillon <dillon@apollo.backplane.com>
Approved by: Kirk McKusick <mckusick@mckusick.com>
Also, in addition to the previous log message, the last change had a fix
for the case where where f.mntfromname is a relative path like da0a.
Submitted by: bde
- Don't use realpath as stat does the right thing.
- Only check ufs filesystems in getmntpt.
- Dont' bother checking that the ufs-mounted-on
device is a special file. It *must* be a special
file, or ufs wouldn't have mounted it.
Submitted by: Paul Saab <ps@yahoo-inc.com>
Submitted by: Kirk McKusick <mckusick@McKusick.COM>
Obtained from: Mckusick, BSDI and a host of others
This exactly matches Kirks sources imported under the
Tag MCKUSICK2. These are as supplied by kirk with one small
change needed to compile under freeBSD.
Some FreeBSD patches will be added back, though many have been
added to Kirk's sources already.
which caused the reference count of a directory to get doubly
decremented.
PR: bin/8030
Reviewed by: nate
Submitted by: Don Lewis <Don.Lewis@tsc.tdk.com>
bug was the cause of the 'freeing free frag' panics that people have been
seeing with FreeBSD/alpha. I have a similar patch to newfs but I've not
finished testing it.
support, which need a final "\n". I only observed one line of
mangled output, but I think there is another one which suffers
from the same problem, and thus I provide a patch that covers
both.
PR: 7483
Reviewed by: phk
Submitted by: Stefan Esser <se@FreeBSD.org>
that `fsck -p' doesn't check multiple slices on the same drive
concurrently. Don't invoke undefined behaviour when searching for
the drive number in strange device names.
PR: 6129
Reviewed by: phk
Submitted by: Yuichi MATSUTAKA <matutaka@osa.att.ne.jp>, but rewritten
by me.
superblock is invalid, fsck looks at the label to help guess where
the next superblock should be. If the partition type is 4.2BSD,
fsck assumed that the block size was valid and divided by it, so
it dumped core if the size was 0.
Initialization of the label was broken almost 3 years ago in rev.1.9
of newfs/newfs.c. Newfs does not change the label at all, so there
is no problem (except the breakage of the automatic search for
backup superblocks) unless something else sets the partition type
to 4.2BSD. However, it is too easy to set partition types to
4.2.BSD by copying an old label or by using a disktab entry to
create the label.
PR: 2537
floating point better in the percentage calculation there to avoid
overflow when there are more than about 20 million fragments. Start
using floating point in the other percentage calculation to avoid
overflow when there are more than about 2 million fragments.
Fixed printf format strings.
Converted sccsid to rcsid.
when there isn't even a filesystem. Attempting to print them tended
to cause SIGSEGV or SIGFPE depending on how far setup() got before it
returned 0. This was broken in the previous revision by removing a
return statement that the previous case depended on falling into.
PR: 4840 (fixed by this commit)
PR: 2537 (possibly fixed by Lite2 merge and later changes. setup()
does more checking now)
something closer to how we used to do it. The Lite2 way is to check the
"fsclean" flag in the superblock and stop there if so (during preen).
We now do the various superblock sanity checks that we used to do before
since it's cheap. We now get the filesystem state summary again instead
of "FILESYSTEM CLEAN; CHECKING SKIPPED" (or whatever).
This will make a number of things easier in the future, as well as (finally!)
avoiding the Id-smashing problem which has plagued developers for so long.
Boy, I'm glad we're not using sup anymore. This update would have been
insane otherwise.
