Date: Tue, 6 Mar 2001 23:53:23 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: rjesup@wgate.com 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 Subject: Re: DJBDNS vs. BIND Message-ID: <200103062353.QAA02845@usr05.primenet.com> In-Reply-To: <ybu3dcqxzzx.fsf@jesup.eng.tvol.net.jesup.eng.tvol.net> from "Randell Jesup" at Mar 06, 2001 06:02:26 PM
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200103062353.QAA02845>