Date: Sun, 20 Sep 1998 10:04:12 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: garbanzo@hooked.net (Alex) Cc: tlambert@primenet.com, eivind@yes.no, julian@whistle.com, Don.Lewis@tsc.tdk.com, current@FreeBSD.ORG Subject: Re: softupdates & fsck Message-ID: <199809201004.DAA14983@usr06.primenet.com> In-Reply-To: <Pine.BSF.4.00.9809200209280.695-100000@zippy.dyn.ml.org> from "Alex" at Sep 20, 98 02:18:09 am
next in thread | previous in thread | raw e-mail | index | archive | help
> System (most likely only the console) froze, hit reset, fsck ran because > the clean bit wasn't set, undeletable directories remained. Rebooted into > single user mode, manually ran fsck -y which cleared the problem (or > appeared to). I've also had problems with odd undeletable files, which I > just booted into single user mode and clri'd (with the same kernel). This is a deeper problem with fsck, unrelated to soft updates. In the worst case, soft updates malfunctioning would result in an FS that is no worse corrupted than if you had been mounted async. In other words, no matter how far gone the thing gets, due to bugs or any other circumstances, fsck is required to be able to correct the FS to an internally self-consistent state. Unless the files could not be deleted because of flags being set (man chflags), in which case, you were required to boot in single user because the secure level was wrong. This could have occurred if you gradually updated your system, but didn't update your rc files in lockstep with your configuration data (ie: the secure level was changed before the fsck, and write access to the devices is denied). > Well, the kernel was built ~Sept 12th. I've cvsup'd numerous times since > then so I don't have exact RCS IDs. If I can build a non CAM kernel some > way to test this, I'd do it. It's time for you to provide a means of duplicating the problem for Julian and Kirk. I have limited access to the test-beds necessary to track something like this to resolution (Julian would be upset if I hacked his reference systems). You should also use the most recent code. I can't remember if by using code from the 12th you are missing as few as one patch or as many as three... > But I'm somewhat leery of building a > CAMified kernel as this has proven itself to be bad idea when combined > with softupdatse. With respect, this has not been proven. It is merely my strong suspicion that this is the case. What's necessary is something to confirm or deny that suspicion, and I can't readily provide that myself, unfortuantely. You may want to try Justin's modifications to the way tagged command queues are managed (posted about to this list, today), since it impacts the area that I am suspicious of, in particular. > > In any case, under no circumstances should the disks be in a > > state that results in files in lost+found if soft updates is > > working. > > Good to see I'm not loosing my mind (yet). No, but I feel like I am... 8-(. I have *seen* working soft updates technology; Matt Day integrated it from the Ganger/Patt Appendix A into our port of the Heidemann framework to Windows 95 more than two years ago. I *know* it's an amazing and useful technology, when it's working. The coincidence of bugs not previously reported and the CAM integration has made me suspicious; but perhaps people were just lax in reporting problems, since I was under the impression everythin was working fine. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809201004.DAA14983>