Date: Thu, 27 Feb 1997 10:37:37 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: kpneal@pobox.com (Kevin P. Neal) Cc: ponds!rivers@dg-rtp.dg.com, freebsd-hackers@freebsd.org Subject: Re: More on bad dir panics Message-ID: <199702271737.KAA00316@phaeton.artisoft.com> In-Reply-To: <1.5.4.32.19970227070248.0089c5f0@mindspring.com> from "Kevin P. Neal" at Feb 27, 97 02:02:48 am
next in thread | previous in thread | raw e-mail | index | archive | help
> At 09:48 PM 2/25/97 -0500, Thomas David Rivers wrote: > > o) Running fsck once isn't enough to restore a file system to > > a semi-usuable state; if you fsck it once, try again, > > you'll sometimes notice more corrections. > > Don't some fscks repeat the check (or parts of it) if they find errors? > Because it's not terribly uncommon (in my experience) for one fsck to > not correct all the errors on a disk (on some of the Unixes I've used -- > I've never fsck'd a FreeBSD box). > > Would looping until a clean check be a bad idea? With some timeout value, > to prevent from fscking eternally? Say, 5-10 times then die? > > Would this be a useful addition? The current fsck used to have a problem where it incorrectly held the wrong reference count on the root directory if it had to create the lost+found directory. I fixed this problem. It may or may not have been reintroduced by the Lite2 integration. Running fsck once *is* enough to restore a file system to a semi-useful state. If you look at the output of the subsequent fcsk's, there is a possibility (rare) that there will be blocks in the allocation bitmap which aren't actually allocated. If these are directories, then it's possible that a reference to a file held in the directory will appear to be there. In general, there is a tiny case where this can happen, and the worst it does is make some blocks temporarily unusable. The case is because the directory name/inode pass doesn't occur before the blocks containing a directory entry are removed from the map. This will happen if the system crashes during a large delete operation during the process of truncating a directory back. While there are a lot of potential problems caused by truncating a directory back (the main one being that you can't preallocate an 8k lost+found directory because it will be truncated back, so there is the potential of needing to allocate a directory block for the entry for lost+found for inode 2, and none are available), these are all very rare fail-safe modes. The resulting FS following the fsck setting the clean bit *is* consistent, and therefore *is* safe to use. The one exception is when root goes over the hard allocation limit, which will push an allocation past the end of the FS. If you have another FS following the first, without a 1 cylinder buffer zone, then you can end up stomping the second FS. If your FS butts up to the end of the disk, you will get "block out of range" errors if you were smart enough to buy SCSI, or undefined errors (including possible cylinder wrap and corruption of the front of the disk) if you weren't. In general, this is not a problem because people don't run disk-gobblers as root except in special cases. The soloution to this problem is to employ logical-to-physical translation layers for enforcement of logical device boundries. In any case, as long as you don't set your reserve to 0, or habitually run as root, fsck should be able to recover any FS to usability in a single run, even if it doesn't recover all unallocated blocks for reuse (if you insist on fixing it, the place to start is pass 4). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702271737.KAA00316>