From owner-freebsd-current Sun Mar 22 15:40:11 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA27465 for freebsd-current-outgoing; Sun, 22 Mar 1998 15:40:11 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA27424 for ; Sun, 22 Mar 1998 15:40:07 -0800 (PST) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id QAA20244; Sun, 22 Mar 1998 16:40:08 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp03.primenet.com, id smtpd020231; Sun Mar 22 16:40:06 1998 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id QAA00401; Sun, 22 Mar 1998 16:40:02 -0700 (MST) From: Terry Lambert Message-Id: <199803222340.QAA00401@usr06.primenet.com> Subject: Re: CURRENT Kernel Status To: karl@mcs.net (Karl Denninger) Date: Sun, 22 Mar 1998 23:40:02 +0000 (GMT) Cc: tlambert@primenet.com, toor@dyson.iquest.net, root@danberlin.resnet.rochester.edu, current@FreeBSD.ORG In-Reply-To: <19980321171211.55116@mcs.net> from "Karl Denninger" at Mar 21, 98 05:12:11 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I know that fsck will not necessarily be able to return the disk > > to the state that it would have been without the failure, but it > > should be possible for it to return it to a self-consistent state. > > > > If it can't, then we need to fix it (IMO). > > It doesn't in this particular case. > > Further, that the METADATA is ok doesn't mean the file contents are > undamaged! You're right; it doesn't. BTW: it's not fsck's job to make user data self-consistent; that's the job of the user data rebuilding program. The only job fsck has is to make the metadata self-consistent. > This last round destroyed or damaged BOTH metadata and the file contents. Certainly, it's bad to have damaged file contents. There's really nothing that can be done about that, except keeping reasonably current backups. In the case of a crash with file contents -- well, that's why database and kernel engineers get paid more than applications jocks. For data you care about, you should use a two stage commit process that guarantees an ordered set of operations, and forces a commit to stable storage. Ideally, you'd do this by mounting the FS you were operating against "sync" and implementing comething very like soft updates, except your graph edges would be described by events important to you, not the FS. 8-). The way in which the current damage took place, where vm object commits were not reliable... well, that's not something you can recover from at all, sorry. 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