Date: Sun, 22 Mar 1998 17:00:18 -0800 (PST) From: Simon Shapiro <shimon@simon-shapiro.org> To: Terry Lambert <tlambert@primenet.com> Cc: current@FreeBSD.ORG, root@danberlin.resnet.rochester.edu, toor@dyson.iquest.net, (Karl Denninger) <karl@mcs.net> Subject: Re: CURRENT Kernel Status Message-ID: <XFMail.980322170018.shimon@simon-shapiro.org> In-Reply-To: <199803222340.QAA00401@usr06.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
... > 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-). Although an excellent idea (not necessarily new :-), this will not protect you from software bugs. Nothing will. > 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. You are right. This braught to mind to question the necessity of having a unified buffer I/O subsystem. In a truely compartmentalized system, the VM could have had nothing to do with data files I/O. Yet, even that would not have saved us from a bug. One of the virtues of Unix is a unified kernel. Any bug effectes any system. Simon 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?XFMail.980322170018.shimon>