Date: Tue, 15 May 2001 11:22:47 -0700 From: Kris Kennaway <kris@obsecurity.org> To: Mikhail Teterin <mi@aldan.algebra.com> Cc: bright@wintelcom.net, bsddiy@163.net, kris@obsecurity.org, grog@lemis.com, tlambert@primenet.com, mckusick@mckusick.com, ru@FreeBSD.org, fs@FreeBSD.org Subject: Re: Re[2]: [kris@obsecurity.org: Re: cvs commit: src/etc rc] Message-ID: <20010515112246.B8619@xor.obsecurity.org> In-Reply-To: <200105151510.f4FFABt62656@aldan.algebra.com>; from mi@aldan.algebra.com on Tue, May 15, 2001 at 11:10:08AM -0400 References: <20010514225533.M2009@fw.wintelcom.net> <200105151510.f4FFABt62656@aldan.algebra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--LpQ9ahxlCli8rRTG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 15, 2001 at 11:10:08AM -0400, Mikhail Teterin wrote: > [cvs-lists removed from CC] > On 14 May, Alfred Perlstein wrote: > > Assuming your database is a serious production quality system it will > > implement its own style of data integrity and consistancy checking > > on top of the filesystems in case it happens to crash. >=20 > Is not this a slightly wrong attitude? Why does a serious production > quality database needs its own checking for problems, which can only > be come from OS if it runs on a serisous production quality OS? Is this truly a relevant comment? There are some things we can fix, and some we can't. If you decide the things we can't fix are important, you should take preventative steps in your code or system design. It's not terribly hard to think up lists of failure scenarios which FreeBSD doesn't correct for, and can't reasonably hope to (what if a magnetic backup medium fails and the admin tries to restore from it? What if a runtime kernel bug causes your server to hand out hokey data? What if a triple-bit memory failure occurs which causes your system to divert that incoming 747 to the wrong runway? What if you run your realtime database server with background fsck and it has filesystem corruption and it hands out corrupted data?). It's only useful, IMO, to talk about problems which can be fixed (and make sure the limitations are documented appropriately somewhere). Kris --LpQ9ahxlCli8rRTG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.5 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7AXP1Wry0BWjoQKURAse6AJ4nIMWOnusM2G8asM8D5ciRqVJeqACg6ol2 izZ1qb6/CH6S/Z489OcCALQ= =1O1C -----END PGP SIGNATURE----- --LpQ9ahxlCli8rRTG-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010515112246.B8619>