From owner-freebsd-current Thu May 17 15: 6:26 2001 Delivered-To: freebsd-current@freebsd.org Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by hub.freebsd.org (Postfix) with ESMTP id 42E0E37B422; Thu, 17 May 2001 15:06:21 -0700 (PDT) (envelope-from david@catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.10.0/8.10.0) id f4HM6Bk85261; Thu, 17 May 2001 15:06:11 -0700 (PDT) Date: Thu, 17 May 2001 15:06:11 -0700 (PDT) From: David Wolfskill Message-Id: <200105172206.f4HM6Bk85261@bunrab.catwhisker.org> To: current@FreeBSD.ORG, jhb@FreeBSD.ORG Subject: Re: background fsck Cc: mckusick@FreeBSD.ORG In-Reply-To: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: X-Loop: FreeBSD.ORG >Date: Thu, 17 May 2001 14:31:55 -0700 (PDT) >From: John Baldwin >Has anyone else been trying out the background fsck? A little; despite my desire to help debug things, getting to a point where doing this is appropriate isn't something I am all too eager to do. Thus, it wasn't exactly "voluntary." :-} >Last night I was working on the ithread code some and managed to panic >my laptop while ejecting a pccard. Anyways, the kernel ate itself while >trying to flush its buffers and I ended up with a dirty filesystem. I've had a couple of occasions when I'd boot my laptop (which resembles yours, as you may recall) from -STABLE into -CURRENT (or vice versa), and xdm would fire up, but not present a login window. Meanwhile, the fan kicks into high gear (indicating that the machine is a tad busy, thankyouverymuch), and I can't get its attention by any means I have been able to discover short of a power-cycle. (At least the button does the job; I didn't need to yank the batteries out.) But lid-closure just shut off the display, no key chord I could find had a noticable effect, nor did removing & re-inserting a PCMCIA card. >I rebooted and let fsck -p do its usual thing, except >that it freaked out. The actual fsck of / proceeded fine (actual fs activity >when I panic'd my machine was very low, so the filesystems weren't corrupted, >just marked dirty). When it got to /usr and /var, however, fsck freaked out >and claimed that the primary superblock didn't match the first alternate. Well, I confess that the first couple of times I had been running -CURRENT and the box wanted a fsck more elaborate than the -p variety, I recalled that there had been recent activity, and I remembered one person's rather unfortunate experience of finding everything sitting in lost+found. Since I had no desire for that to happen, I booted -STABLE instead: single-user mode, "fsck -p". Wasn't quite happy with a couple of file systems, so I did manual "fsck" (still under -STABLE) on each of those. Finally, system said things were OK; I was able to do a "mount-a", so after that, I did a "reboot" into -CURRENT. Much to my surprise (and some chagrin), those 2 file systems that needed the extra attention (/var and -CURRENT's /usr, if I recall correctly) didn't pass muster with -CURRENT's fsck; it wanted a manual fsck of those, no question about it. Since they passed -STABLE's fsck, I figured they weren't likely in *too* terribly bad shape, so I went ahead and did the manual fsck, per request. And in each case, I had a similar symptom (re: primary & first alternate superblock mismatch). I did wonder about making a choice just between those two, without checking for one of the other alternates (some sort of "voting protocol" -- though I wouldn't be too terribly keen on making fsck unecessarily complicated, certainly). But under the circumstances, I wanted to run -CURRENT, so I didn't see that I had a great deal of choice in the matter (regardless of what I was being asked), so I told it to go ahead. Following those manual fscks, I re-booted into multi-user mode, and things worked normally (as far as I can tell). >At this point I first had a heart attack. I believe that a technical term for that literary device is "hyperbole". :-) >Once I recovered from that, I attempted >read-only mounts of /usr and /var which did succeed, except that each mount >spewed out a message to the kernel console about losing x files and y blocks. >Confident that my fs wasn't totally hosed after doing some ls's, I unmounted >/usr and /var and ran a non-preen fsck on them, which insisted on using an >alternate superblock, but otherwise proceeded fine (except that it seemed to >take longer than usual). Once the fscks's finished, it seemed to be all ok. >Is anyone else seeing any weird stuff like this? I've never had fsck complain >about the superblocks after a crash before. As noted, it's happened a couple of times for me. Generally, somewhat inopportune times (almost by definition), so I wasn't really able to take the time to sit back, take notes, and report back much that was coherent. And I was under the impression that much of this was "under construction" anyhow, so the value of any report I maight make was somewhat open to question (from my perspective, anyhow). >... >Hmm, that's odd, I did have soft updates on on /usr and /var before the crash. >It seems to be off now. :( That also happened to me. I thought it odd at the time, but forgot to mention it.... At least I have some reason to believe I was unlikely to have been hallucinating about that.... Cheers, david -- David H. Wolfskill david@catwhisker.org As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message