7.7. What are the consequences of "fsck -s" (salvaging the freelist)?
Description
This article is from the 3b1 computers FAQ, by John B. Bunch with numerous contributions by others.
7.7. What are the consequences of "fsck -s" (salvaging the freelist)?
Jim Adams sent some information regarding the uses (and dangers) of salvaging the freelist using the fsck(1M) command.
fsck(1M) provides a method of salvaging and reconstructing the freelist maintained by the UNIX filesystem. It is dangerous to haphazardly do anything with the filesystem, as well as just reconstructing the freelist. If the filesystem isn't in a good state, it's possible that the freelist could be further damaged by just salvaging it. fsck(1M) will salvage the freelist when necessary, or when the question "SALVAGE (Y/N)?" is answered "yes".
Jim has said that the alternative method, fsck -S, should be used if you wish to salvage the freelist. The salvage will only be done if the filesystem is properly constructed, and nothing damaging could occur by its reconstruction. If errors are found during the fsck phases, other than errors like "POSSIBLE FILE SIZE ERROR I=nnn" (which occurs from sparse files, also known as files with holes in them) the salvage will not be done.
fsck(1M) is designed to be run on a mounted root filesystem, so long as the block device is used and the system is in a quiet state. fsck(1M) can be run on the raw/character device when the filesystem isn't mounted, and this is generally much faster. fsck(1M) will automatically reboot the system without sync'ing, if the "mounted" root filesystem was modified, just as you should (since the in-core image of the filesystem would be different). There is no "re-mount" facility on the UNIX PC, otherwise the root filesystem could just be remounted.
Another suggestion made was to run "fsck -D" to check directories for bad blocks. This takes longer, but is considered worth it. (fsck -D is similar to the MSDOS CHKDSK facility.)
Continue to:
My Books
