Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!haven.umd.edu!umd5.umd.edu!elea.umd.edu!mark From: mark@elea.umd.edu (Mark Sienkiewicz) Newsgroups: comp.os.386bsd.development Subject: Re: mount a dirty file system without fsck (was Re: what is fs_clean for?) Date: 11 Oct 1993 17:01:34 GMT Organization: Zeno, IPST, University of Maryland Lines: 29 Message-ID: <29c3he$3ql@hecate.umd.edu> References: <2945gj$i0h@acsc.com> NNTP-Posting-Host: elea.umd.edu In article <2945gj$i0h@acsc.com>, Jerry Chen <jerry@acsc.com> wrote: >As I learn more and more from the UFS source code, it seems >dangerous to me if we allow the BSD system to mount a dirty UFS file system. >Here is one problem: ... he describes how this can happen: > valid inode1 ----> valid indirect block ----> obsolete data block <---+ > | > | > valid inode2 ----> valid indirect block ------------------------------+ ... he describes a solution that causes a performance hit, though doesn't look too painful >Please correct me if I missing anything. Thanks. Your analysis is correct. This is a situation that can happen if you mount a filesystem that got dirtied in a particular way. It's not some big problem, though. If the system is rebooting automatically, fsck -p will see the filesystem marked dirty, then clean it before it gets mounted. If the system is being operated by a human, then the human should be able to tell it what to do. The human then decides whether to take the risk implied in running on a dirty filesystem, or whether he knows enough about the circumstances of the crash that he can safely skip the 5 or 10 minutes to check all the disks.