7848b25edd
This fixes a long-standing but very obscure bug in fsck_ffs when it is run with the -R (rerun after unexpected errors). It only occurs if fsck_ffs finds duplicate blocks and they are all contained in inodes that reside in the first block of inodes (typically among the first 128 inodes). Rather than use the usual ginode() interface to walk through the inodes in pass1, there is a special optimized `getnextinode()' routine for walking through all the inodes. It has its own private buffer for reading the inode blocks. If pass 1 finds duplicate blocks it runs pass 1b to find all the inodes that contain these duplicate blocks. Pass 1b also uses the `getnextinode()' to search for the inodes with duplicate blocks. Pass 1b stops when all the duplicate blocks have been found. If all the duplicate blocks are found in the first block of inodes, then the getnextinode cache holds this block of bad inodes. The subsequent cleanup of the inodes in passes 2-5 is done using ginode() which uses the regular fsck_ffs cache. When fsck_ffs restarts, pass1() calls setinodebuf() to point at the first block of inodes. When it calls getnextinode() to get inode 2, getnextino() sees that its private cache already has the first set of inodes loaded and starts using them. They are of course the trashed inodes left over from the previous run of pass1b(). The fix is to always invalidate the getnextinode cache when calling setinodebuf(). Reported by: Chuck Silvers Tested by: Chuck Silvers MFC after: 3 days Sponsored by: Netflix |
||
|---|---|---|
| .. | ||
| dir.c | ||
| ea.c | ||
| fsck_ffs.8 | ||
| fsck.h | ||
| fsutil.c | ||
| gjournal.c | ||
| globs.c | ||
| inode.c | ||
| main.c | ||
| Makefile | ||
| Makefile.depend | ||
| pass1.c | ||
| pass1b.c | ||
| pass2.c | ||
| pass3.c | ||
| pass4.c | ||
| pass5.c | ||
| setup.c | ||
| suj.c | ||
| utilities.c | ||