Age | Commit message (Collapse) | Author |
|
|
|
- If the lost+found directory is created by fsck, it will do a cacheino()
which sets the inoinfo's i_parent and i_dotdot to 0, but they never get
set to ROOTINO. This means that propagate will never find lost+found and
its descendents, subdirectories will remain DSTATE (instead of DFOUND)
even though they are correctly linked in, and pass4.c will try to
clear them unsuccessfully, thinking that there is no link count from the
DSTATE directory's parent. The result is that you need to run fsck twice
and get "EXTRANEOUS HARD LINK TO DIRECTORY" error (which are unexpected
and fatal when running in preen mode). The fix is to set i_parent and
i_dotdot to "parent" after the second cacheino() call in dir.c:allocdir().
From NetBSD via FreeBSD.
- modify propagate() so it be able to start from any point in the tree.
- minor tweaks to get more generality in state propagation.
In other words fsck doesn't leave unremovable directories anymore.
costa@ ok.
|
|
|
|
|
|
|
|
From FreeBSD with little changes.
art@ ok.
|
|
FreeBSD's log:
> The ffs superblock includes a 128-byte region for use by temporary
> in-core pointers to summary information. An array in this region
> (fs_csp) could overflow on filesystems with a very large number of
> cylinder groups (~16000 on i386 with 8k blocks). When this happens,
> other fields in the superblock get corrupted, and fsck refuses to
> check the filesystem.
>
> Solve this problem by replacing the fs_csp array in 'struct fs'
> with a single pointer, and add padding to keep the length of the
> 128-byte region fixed. Update the kernel and userland utilities
> to use just this single pointer.
>
> With this change, the kernel no longer makes use of the superblock
> fields 'fs_csshift' and 'fs_csmask'. Add a comment to newfs/mkfs.c
> to indicate that these fields must be calculated for compatibility
> with older kernels.
art@ ok.
|
|
It allocates directory inode in the same cylinder group as a parent
directory in. This speedup file/directory intensive operations on
a big file systems in times.
Don't forget to recompile fsck_ffs with updated fs.h or you will get
"VALUES IN SUPER BLOCK DISAGREE WITH THOSE IN FIRST ALTERNATE" at
the next boot. In any case you can ignore this error safely.
Requested by deraadt@
|
|
|
|
|
|
to check if it builds.
|
|
We had this in the tree 1997, but it went away because it was too close to
release.
Ok: csapuntz@
(as a size note: It's really good to test fsck when you are torture testing
the filesystems)
|
|
|
|
|
|
|
|
millert@ ok
|
|
|
|
|
|
done later.. contact me if you want to help)
|
|
|
|
|
|
|
|
|
|
is used instead; kwesterback@home.com
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
bad fs images triggers.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Ian Dowse <iedowse@maths.tcd.ie>
|
|
|
|
|
|
The following small diff fixes the annoying fsck bug that causes it to
need to be run twice to end up with correct reference counts for inodes
for directories that had subdirectories relocated into the lost+found
directory.
I found the need to rerun *extremely* annoying. This fix causes the
count to be correctly adjusted later in pass 4 by correctly stating
the parent reference count.
Note that the parent reference count is incremented when the directory
entry is made (for ".."), but is not really there in the case of a
directory that does not make an entry in its parent dir.
This can be tested by waiting for the inode sync after cd'ing from a
shell into a test fs. Then you "mkdir xxx yyy zzz", wait a second,
and hit the machine reset button.
|
|
|
|
|
|
If a directory somehow develops a hole (that is a block pointer
that has a value of zero), fsck would give the filesystem a clean
bill of health, but the kernel would panic when accessing the
directory with the hole. Fsck now checks for holes in directories.
If found in preen mode, fsck fails. In manual mode, it can be
directed to shorten the directory to the beginning of the hole. A
more complete solution would be to allocate a block to fill the
hole. However, this is a lot more work for a `cannot happen' error,
so the extra effort seems unwarranted.
|
|
|
|
|
|
|