Date: Sun, 22 Mar 1998 23:40:02 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: karl@mcs.net (Karl Denninger) Cc: tlambert@primenet.com, toor@dyson.iquest.net, root@danberlin.resnet.rochester.edu, current@FreeBSD.ORG Subject: Re: CURRENT Kernel Status Message-ID: <199803222340.QAA00401@usr06.primenet.com> In-Reply-To: <19980321171211.55116@mcs.net> from "Karl Denninger" at Mar 21, 98 05:12:11 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199803222340.QAA00401>