From owner-freebsd-chat Tue Mar 6 15:53:51 2001 Delivered-To: freebsd-chat@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id 1383D37B719 for ; Tue, 6 Mar 2001 15:53:49 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id QAA25922; Tue, 6 Mar 2001 16:47:56 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp04.primenet.com, id smtpdAAA_ma4wY; Tue Mar 6 16:47:43 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id QAA02845; Tue, 6 Mar 2001 16:53:23 -0700 (MST) From: Terry Lambert Message-Id: <200103062353.QAA02845@usr05.primenet.com> Subject: Re: DJBDNS vs. BIND To: rjesup@wgate.com Date: Tue, 6 Mar 2001 23:53:23 +0000 (GMT) Cc: wes@softweyr.com (Wes Peters), mwm@mired.org (Mike Meyer), tlambert@primenet.com (Terry Lambert), dillon@earth.backplane.com (Matt Dillon), bright@wintelcom.net (Alfred Perlstein), josb@cncdsl.com, chat@FreeBSD.ORG In-Reply-To: from "Randell Jesup" at Mar 06, 2001 06:02:26 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The reductio ad absurdum of putting things in text files for fear of binary file corruption not being as recoverable as text, is to store the kernel itself as text, in order to make it recoverable, since a binary file is "too hard to recover". I think people are using "binary file recovery is hard" as code for "I didn't do backups, and humans can at least salvage some data from a corrupt text file, if it's not too corrupt". We had an interesting problem on the InterJet which I think is applicable; it had to do with mmap() and copy-on-write. The cron program opened up the password data, and assumed that it was going to get back a pointer to a static area with getpwent(), but instead got back a pointer to a copy-on-write area. It updated the contents of this "static" data (cron still does this today), and went about it's business. This resulted in the page being marked dirty, and through some confusion in the kernel, since the file was open read-only, and there was no reasonable backing store, occasionally something would force paging, and the dirty passwd database file page would get stomped over top of the crontab contents. In other words, we had a nice text file, which became unrecoverably corrupt, through no fault of its own. Of course, everything quit working, but connectivity was not a problem, so the problem would land on my desk, since it required an engineering intervention (only engineering had the necessary acess to resolve the problem, and then only with customer cooperation). I don't see text files as being any safer than binary, except in the case of human recovery in the absence of a backup. I would argue that human recovery is not a useful scenario, even in the absence of a backup. All the data on the system is stored in one big binary file called a "device", with the format only understood by the kernel and special tools (e.g. fsck, tunefs, newfs, etc.). The weakest link is the weakest link, and we shouldn't try to pretend it isn't, or we'll only get ourselves into trouble. 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-chat" in the body of the message