From owner-freebsd-fs Sun May 13 10:59: 7 2001 Delivered-To: freebsd-fs@freebsd.org Received: from privatecube.privatelabs.com (privatecube.privatelabs.com [63.114.185.254]) by hub.freebsd.org (Postfix) with ESMTP id 4BEA337B422; Sun, 13 May 2001 10:58:49 -0700 (PDT) (envelope-from mi@misha.privatelabs.com) Received: from misha.privatelabs.com (root@misha.plten [10.0.0.106]) by privatecube.privatelabs.com (8.9.3/8.9.2) with ESMTP id NAA30131; Sun, 13 May 2001 13:19:26 -0400 Received: (from mi@localhost) by misha.privatelabs.com (8.11.3/8.11.1) id f4DHwgl09955; Sun, 13 May 2001 13:58:42 -0400 (EDT) (envelope-from mi) From: Mikhail Teterin Message-Id: <200105131758.f4DHwgl09955@misha.privatelabs.com> Subject: Re: [kris@obsecurity.org: Re: cvs commit: src/etc rc] In-Reply-To: <20010512023602.A40616@xor.obsecurity.org> "from Kris Kennaway at May 12, 2001 02:36:02 am" To: Kris Kennaway Date: Sun, 13 May 2001 13:58:42 -0400 (EDT) Cc: Kirk McKusick , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, Ruslan Ermilov , fs@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Working under the assumption that the only time fsck is likely to fail > in this manner is if there are FS errors which can't be resolved in > the background, and which may result in further FS damage if left > uncorrected, the best option seems to be to take some action which > prevents this damage. > > The best series of actions might be the following: > > 1) Downgrade the FS to readonly mode. Can't a foreground fsck be run at this moment? Having to reboot for anything is rather ugly... I'm sure there is a reason it can not, I'm just wondering, what that reason is. Thanks! -mi > 2) syslog(LOG_EMERG, "Unrecoverable error in background check of %s, > FS downgraded to readonly mode. Reboot in 60 seconds to attempt to > repair the error. Kill PID %d now to abort.", ...) > > 3) Reboot in 60 seconds To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sun May 13 16:43:13 2001 Delivered-To: freebsd-fs@freebsd.org Received: from beastie.mckusick.com (beastie.mckusick.com [209.31.233.184]) by hub.freebsd.org (Postfix) with ESMTP id F108737B423; Sun, 13 May 2001 16:43:04 -0700 (PDT) (envelope-from mckusick@mckusick.com) Received: from beastie.mckusick.com (localhost [127.0.0.1]) by beastie.mckusick.com (8.9.3/8.9.3) with ESMTP id QAA21879; Sun, 13 May 2001 16:42:55 -0700 (PDT) (envelope-from mckusick@beastie.mckusick.com) Message-Id: <200105132342.QAA21879@beastie.mckusick.com> To: Mikhail Teterin Subject: Re: [kris@obsecurity.org: Re: cvs commit: src/etc rc] Cc: Kris Kennaway , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, Ruslan Ermilov , fs@FreeBSD.org In-Reply-To: Your message of "Sun, 13 May 2001 13:58:42 EDT." <200105131758.f4DHwgl09955@misha.privatelabs.com> Date: Sun, 13 May 2001 16:42:55 -0700 From: Kirk McKusick Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > From: Mikhail Teterin > Subject: Re: [kris@obsecurity.org: Re: cvs commit: src/etc rc] > In-Reply-To: <20010512023602.A40616@xor.obsecurity.org> "from Kris Kennaway at > May 12, 2001 02:36:02 am" > To: Kris Kennaway > Date: Sun, 13 May 2001 13:58:42 -0400 (EDT) > CC: Kirk McKusick , cvs-committers@FreeBSD.org, > cvs-all@FreeBSD.org, Ruslan Ermilov , fs@FreeBSD.org > > > Working under the assumption that the only time fsck is likely to fail > > in this manner is if there are FS errors which can't be resolved in > > the background, and which may result in further FS damage if left > > uncorrected, the best option seems to be to take some action which > > prevents this damage. > > > > The best series of actions might be the following: > > > > 1) Downgrade the FS to readonly mode. > > Can't a foreground fsck be run at this moment? Having to reboot for > anything is rather ugly... I'm sure there is a reason it can not, I'm > just wondering, what that reason is. Thanks! > > -mi Indeed, a foreground fsck can be run once the downgrade to read-only has happened. However, doing so automatically is unlikely to be useful since nearly every error that would get us to this point will also cause an `fsck -p' to fail. So, at this point a system administrator is going to have to intervene to do a manual fsck. Once the downgrade to read-only has happened, no further filesystem damage can occur, so there is not a great rush to run the manual fsck. However, if the affected filesystem is something crucial like /var, the system may not run at all well until the problem is fixed. Kirk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sun May 13 18:23:15 2001 Delivered-To: freebsd-fs@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id BBB5C37B422 for ; Sun, 13 May 2001 18:23:12 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.3/8.11.3) with SMTP id f4E1Mqf64018; Sun, 13 May 2001 21:22:53 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sun, 13 May 2001 21:22:52 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Poul-Henning Kamp Cc: Ian Dowse , freebsd-fs@freebsd.org Subject: Re: vflush() In-Reply-To: <5153.989736890@critter> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 13 May 2001, Poul-Henning Kamp wrote: > >As a side-effect, this corrects a vnode leak that currently exists > >in devfs, as there was a vput() missing for the case where vflush() > >failed. This bug could result in idle devfs filesystems that refuse > >to unmount. > > oops... Yeah, I noticed that problem on a number of occasions, it may have been this bug. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon May 14 6:41:49 2001 Delivered-To: freebsd-fs@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 1BBDC37B42C; Mon, 14 May 2001 06:41:40 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.3/8.11.3) with SMTP id f4EDf6f70707; Mon, 14 May 2001 09:41:06 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Mon, 14 May 2001 09:41:06 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Kirk McKusick Cc: Mikhail Teterin , Kris Kennaway , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, Ruslan Ermilov , fs@FreeBSD.org Subject: Re: [kris@obsecurity.org: Re: cvs commit: src/etc rc] In-Reply-To: <200105132342.QAA21879@beastie.mckusick.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 13 May 2001, Kirk McKusick wrote: > > Can't a foreground fsck be run at this moment? Having to reboot for > > anything is rather ugly... I'm sure there is a reason it can not, I'm > > just wondering, what that reason is. Thanks! > > Indeed, a foreground fsck can be run once the downgrade to read-only > has happened. However, doing so automatically is unlikely to be useful > since nearly every error that would get us to this point will also > cause an `fsck -p' to fail. So, at this point a system administrator > is going to have to intervene to do a manual fsck. Once the downgrade > to read-only has happened, no further filesystem damage can occur, so > there is not a great rush to run the manual fsck. However, if the > affected filesystem is something crucial like /var, the system may not > run at all well until the problem is fixed. We've already discussed this scenario on -arch, but for those that missed the discussion, here's a couple of observations about this scenario that are worth keeping in mind: 1) If soft updates and the disk controller are operating normally, this will never happen: this type of failure of fsck can only happen when the constraints described by soft updates disk write ordering are violated. 2) This suggests that the failure in question is a function of a soft updates failure, or a hardware failure. In such a scenario, it is possible for fsck -p to accept the file system as clean, and allow it to be write-mounted in the current scenario, which would result in a (possibly rapid) kernel failure due to the on-disk file system violating normal UFS/FFS writing contraints (no cycles, etc, etc). I.e., if you've accepted that soft updates is pretty correctly implemented, and that your hardware is moderately correct, this scenario is unlikely to occur, and if it does, you're up a creek anyway. One thing that would be nice to see, feature-wise, is a: BACKGROUND_FSCK="NO" # enable/disable background fscking at boot style of entry in rc.conf, with a default of "YES", but a "NO" forcing a normal fsck -p in the foreground. This can currently be controlled in /etc/fstab, but providing an easy on/off toggle for recovery might be useful. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon May 14 9:33:34 2001 Delivered-To: freebsd-fs@freebsd.org Received: from cheddar.netmonger.net (cheddar.netmonger.net [209.54.21.140]) by hub.freebsd.org (Postfix) with ESMTP id DFFF937B42C; Mon, 14 May 2001 09:33:27 -0700 (PDT) (envelope-from chris@cheddar.netmonger.net) Received: (from chris@localhost) by cheddar.netmonger.net (8.8.8/8.8.8) id MAA26934; Mon, 14 May 2001 12:32:34 -0400 (EDT) Message-ID: <20010514123233.A23290@netmonger.net> Date: Mon, 14 May 2001 12:32:34 -0400 From: Christopher Masto To: Robert Watson , Kirk McKusick Cc: Mikhail Teterin , Kris Kennaway , cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, Ruslan Ermilov , fs@FreeBSD.ORG Subject: Re: [kris@obsecurity.org: Re: cvs commit: src/etc rc] References: <200105132342.QAA21879@beastie.mckusick.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: ; from Robert Watson on Mon, May 14, 2001 at 09:41:06AM -0400 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, May 14, 2001 at 09:41:06AM -0400, Robert Watson wrote: > I.e., if you've accepted that soft updates is pretty correctly > implemented, and that your hardware is moderately correct, this scenario > is unlikely to occur, and if it does, you're up a creek anyway. One thing > that would be nice to see, feature-wise, is a: > > BACKGROUND_FSCK="NO" # enable/disable background fscking at boot > > style of entry in rc.conf, with a default of "YES" I think that's a good idea. I had the same thought this morning, envisioning a co-lo scenario where one might not want to accidentally go home while an fsck is still running. (I know, there are various reasons a problem like that is extremely unlikely, but a bit of paranoia is a good thing in sysadmins). A global option like that in a place that's frequently checked when configuring a machine seems sensible. -- Christopher Masto Senior Network Monkey NetMonger Communications chris@netmonger.net info@netmonger.net http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon May 14 14:46: 2 2001 Delivered-To: freebsd-fs@freebsd.org Received: from privatecube.privatelabs.com (privatecube.privatelabs.com [63.114.185.254]) by hub.freebsd.org (Postfix) with ESMTP id DD62F37B422; Mon, 14 May 2001 14:45:59 -0700 (PDT) (envelope-from mi@aldan.algebra.com) Received: from misha.privatelabs.com (root@misha.plten [10.0.0.106]) by privatecube.privatelabs.com (8.9.3/8.9.2) with ESMTP id RAA14351; Mon, 14 May 2001 17:06:36 -0400 From: mi@aldan.algebra.com Received: from misha.privatelabs.com (mi@localhost [127.0.0.1]) by misha.privatelabs.com (8.11.3/8.11.1) with ESMTP id f4ELjrq13574; Mon, 14 May 2001 17:45:55 -0400 (EDT) (envelope-from mi@aldan.algebra.com) Message-Id: <200105142145.f4ELjrq13574@misha.privatelabs.com> Date: Mon, 14 May 2001 17:45:52 -0400 (EDT) Reply-To: mi@aldan.algebra.com Subject: Re: [kris@obsecurity.org: Re: cvs commit: src/etc rc] To: mckusick@mckusick.com Cc: kris@obsecurity.org, ru@FreeBSD.org, fs@FreeBSD.org In-Reply-To: <200105132342.QAA21879@beastie.mckusick.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 13 May, Kirk McKusick wrote: >> > 1) Downgrade the FS to readonly mode. >> >> Can't a foreground fsck be run at this moment? Having to reboot for >> anything is rather ugly... I'm sure there is a reason it can not, I'm >> just wondering, what that reason is. Thanks! > Indeed, a foreground fsck can be run once the downgrade to read-only > has happened. However, doing so automatically is unlikely to be useful > since nearly every error that would get us to this point will also > cause an `fsck -p' to fail. So, at this point a system administrator > is going to have to intervene to do a manual fsck. Once the downgrade > to read-only has happened, no further filesystem damage can occur, so > there is not a great rush to run the manual fsck. However, if the > affected filesystem is something crucial like /var, the system may not > run at all well until the problem is fixed. So, Kris' proposition to keep rebooting is not really good either... Perhaps, fsck needs to be modified to do the logging by itself -- on different levels and priorities instead of relying on the logger? -mi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon May 14 16:28:15 2001 Delivered-To: freebsd-fs@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id 1E92137B423; Mon, 14 May 2001 16:28:07 -0700 (PDT) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id QAA24616; Mon, 14 May 2001 16:28:04 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp05.primenet.com, id smtpdAAAHUaO.V; Mon May 14 16:27:55 2001 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id QAA05923; Mon, 14 May 2001 16:34:07 -0700 (MST) From: Terry Lambert Message-Id: <200105142334.QAA05923@usr06.primenet.com> Subject: Re: [kris@obsecurity.org: Re: cvs commit: src/etc rc] To: mckusick@mckusick.com (Kirk McKusick) Date: Mon, 14 May 2001 23:34:02 +0000 (GMT) Cc: mi@misha.privatelabs.com (Mikhail Teterin), kris@obsecurity.org (Kris Kennaway), cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, ru@FreeBSD.ORG (Ruslan Ermilov), fs@FreeBSD.ORG In-Reply-To: <200105132342.QAA21879@beastie.mckusick.com> from "Kirk McKusick" at May 13, 2001 04:42:55 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-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > Working under the assumption that the only time fsck is likely to fail > > > in this manner is if there are FS errors which can't be resolved in > > > the background, and which may result in further FS damage if left > > > uncorrected, the best option seems to be to take some action which > > > prevents this damage. > > > > > > The best series of actions might be the following: > > > > > > 1) Downgrade the FS to readonly mode. > > > > Can't a foreground fsck be run at this moment? Having to reboot for > > anything is rather ugly... I'm sure there is a reason it can not, I'm > > just wondering, what that reason is. Thanks! > > Indeed, a foreground fsck can be run once the downgrade to read-only > has happened. However, doing so automatically is unlikely to be useful > since nearly every error that would get us to this point will also > cause an `fsck -p' to fail. So, at this point a system administrator > is going to have to intervene to do a manual fsck. Once the downgrade > to read-only has happened, no further filesystem damage can occur, so > there is not a great rush to run the manual fsck. However, if the > affected filesystem is something crucial like /var, the system may not > run at all well until the problem is fixed. Rebooting is a good idea, in any case, since you really can't trust the results of programs run from a bogified FS. So it would not be safe, for example, to fsck it, get it clean, and then remount it read/write, since the programs you are running now came from a damaged FS (seriously damaged, if a background fsck doesn't succeed). 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-fs" in the body of the message From owner-freebsd-fs Mon May 14 19:26:54 2001 Delivered-To: freebsd-fs@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 6292D37B424; Mon, 14 May 2001 19:26:33 -0700 (PDT) (envelope-from grog@lemis.com) Received: by wantadilla.lemis.com (Postfix, from userid 1004) id 6C4896ACBC; Tue, 15 May 2001 11:56:30 +0930 (CST) Date: Tue, 15 May 2001 11:56:30 +0930 From: Greg Lehey To: Terry Lambert Cc: Kirk McKusick , Mikhail Teterin , Kris Kennaway , cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, Ruslan Ermilov , fs@FreeBSD.ORG Subject: Re: [kris@obsecurity.org: Re: cvs commit: src/etc rc] Message-ID: <20010515115630.H59553@wantadilla.lemis.com> References: <200105132342.QAA21879@beastie.mckusick.com> <200105142334.QAA05923@usr06.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200105142334.QAA05923@usr06.primenet.com>; from tlambert@primenet.com on Mon, May 14, 2001 at 11:34:02PM +0000 Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Monday, 14 May 2001 at 23:34:02 +0000, Terry Lambert wrote: >>>> Working under the assumption that the only time fsck is likely to fail >>>> in this manner is if there are FS errors which can't be resolved in >>>> the background, and which may result in further FS damage if left >>>> uncorrected, the best option seems to be to take some action which >>>> prevents this damage. >>>> >>>> The best series of actions might be the following: >>>> >>>> 1) Downgrade the FS to readonly mode. >>> >>> Can't a foreground fsck be run at this moment? Having to reboot for >>> anything is rather ugly... I'm sure there is a reason it can not, I'm >>> just wondering, what that reason is. Thanks! >> >> Indeed, a foreground fsck can be run once the downgrade to read-only >> has happened. However, doing so automatically is unlikely to be useful >> since nearly every error that would get us to this point will also >> cause an `fsck -p' to fail. So, at this point a system administrator >> is going to have to intervene to do a manual fsck. Once the downgrade >> to read-only has happened, no further filesystem damage can occur, so >> there is not a great rush to run the manual fsck. However, if the >> affected filesystem is something crucial like /var, the system may not >> run at all well until the problem is fixed. > > Rebooting is a good idea, in any case, since you really can't > trust the results of programs run from a bogified FS. This sounds like a Microsoft idea. Isn't that the reason why they want you to reboot if you do something like changing the default router? > So it would not be safe, for example, to fsck it, get it clean, and > then remount it read/write, since the programs you are running now > came from a damaged FS (seriously damaged, if a background fsck > doesn't succeed). I don't know if this can happen. If it can, there should be other ways of solving it. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon May 14 19:33:42 2001 Delivered-To: freebsd-fs@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-32.dsl.lsan03.pacbell.net [63.207.60.32]) by hub.freebsd.org (Postfix) with ESMTP id A60B037B43C; Mon, 14 May 2001 19:33:34 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id BF94366C8C; Mon, 14 May 2001 19:33:33 -0700 (PDT) Date: Mon, 14 May 2001 19:33:33 -0700 From: Kris Kennaway To: Greg Lehey Cc: Terry Lambert , Kirk McKusick , Mikhail Teterin , Kris Kennaway , cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, Ruslan Ermilov , fs@FreeBSD.ORG Subject: Re: [kris@obsecurity.org: Re: cvs commit: src/etc rc] Message-ID: <20010514193332.A85465@xor.obsecurity.org> References: <200105132342.QAA21879@beastie.mckusick.com> <200105142334.QAA05923@usr06.primenet.com> <20010515115630.H59553@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="M9NhX3UHpAaciwkO" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010515115630.H59553@wantadilla.lemis.com>; from grog@lemis.com on Tue, May 15, 2001 at 11:56:30AM +0930 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --M9NhX3UHpAaciwkO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 15, 2001 at 11:56:30AM +0930, Greg Lehey wrote: > > Rebooting is a good idea, in any case, since you really can't > > trust the results of programs run from a bogified FS.=20 >=20 > This sounds like a Microsoft idea. Isn't that the reason why they > want you to reboot if you do something like changing the default > router? No, they're different: one is rebooting to recover from an unknown, catastrophic error from which it may be dangerous to continue, and the other is rebooting to recover from a non-fatal condition which the programmers have not bothered to handle online. Kris --M9NhX3UHpAaciwkO 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 iD8DBQE7AJV8Wry0BWjoQKURApTzAKD/Bv/ODm2qb9CAbODgU/TLqCFepACghpk6 R53Erb236mUhR0ShCkSD4MU= =4+fv -----END PGP SIGNATURE----- --M9NhX3UHpAaciwkO-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon May 14 19:36: 8 2001 Delivered-To: freebsd-fs@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 7B22537B423; Mon, 14 May 2001 19:35:59 -0700 (PDT) (envelope-from grog@lemis.com) Received: by wantadilla.lemis.com (Postfix, from userid 1004) id 343E16ACBE; Tue, 15 May 2001 12:05:58 +0930 (CST) Date: Tue, 15 May 2001 12:05:58 +0930 From: Greg Lehey To: Kris Kennaway Cc: Terry Lambert , Kirk McKusick , Mikhail Teterin , cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, Ruslan Ermilov , fs@FreeBSD.ORG Subject: Re: [kris@obsecurity.org: Re: cvs commit: src/etc rc] Message-ID: <20010515120558.M59553@wantadilla.lemis.com> References: <200105132342.QAA21879@beastie.mckusick.com> <200105142334.QAA05923@usr06.primenet.com> <20010515115630.H59553@wantadilla.lemis.com> <20010514193332.A85465@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010514193332.A85465@xor.obsecurity.org>; from kris@obsecurity.org on Mon, May 14, 2001 at 07:33:33PM -0700 Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Monday, 14 May 2001 at 19:33:33 -0700, Kris Kennaway wrote: > On Tue, May 15, 2001 at 11:56:30AM +0930, Greg Lehey wrote: > >>> Rebooting is a good idea, in any case, since you really can't >>> trust the results of programs run from a bogified FS. >> >> This sounds like a Microsoft idea. Isn't that the reason why they >> want you to reboot if you do something like changing the default >> router? > > No, they're different: one is rebooting to recover from an unknown, > catastrophic error from which it may be dangerous to continue, and the > other is rebooting to recover from a non-fatal condition which the > programmers have not bothered to handle online. It's a matter of degree. Since the programmers haven't bothered to handle it online, it's potentially dangerous to continue without rebooting. Given enough effort, we could also recover from the failed fsck. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon May 14 20:27:21 2001 Delivered-To: freebsd-fs@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-32.dsl.lsan03.pacbell.net [63.207.60.32]) by hub.freebsd.org (Postfix) with ESMTP id 83A8937B422; Mon, 14 May 2001 20:27:08 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id EE75966C8C; Mon, 14 May 2001 20:27:07 -0700 (PDT) Date: Mon, 14 May 2001 20:27:07 -0700 From: Kris Kennaway To: Greg Lehey Cc: Kris Kennaway , Terry Lambert , Kirk McKusick , Mikhail Teterin , cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, Ruslan Ermilov , fs@FreeBSD.ORG Subject: Re: [kris@obsecurity.org: Re: cvs commit: src/etc rc] Message-ID: <20010514202707.B93481@xor.obsecurity.org> References: <200105132342.QAA21879@beastie.mckusick.com> <200105142334.QAA05923@usr06.primenet.com> <20010515115630.H59553@wantadilla.lemis.com> <20010514193332.A85465@xor.obsecurity.org> <20010515120558.M59553@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="eAbsdosE1cNLO4uF" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010515120558.M59553@wantadilla.lemis.com>; from grog@lemis.com on Tue, May 15, 2001 at 12:05:58PM +0930 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --eAbsdosE1cNLO4uF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 15, 2001 at 12:05:58PM +0930, Greg Lehey wrote: > On Monday, 14 May 2001 at 19:33:33 -0700, Kris Kennaway wrote: > > On Tue, May 15, 2001 at 11:56:30AM +0930, Greg Lehey wrote: > > > >>> Rebooting is a good idea, in any case, since you really can't > >>> trust the results of programs run from a bogified FS. > >> > >> This sounds like a Microsoft idea. Isn't that the reason why they > >> want you to reboot if you do something like changing the default > >> router? > > > > No, they're different: one is rebooting to recover from an unknown, > > catastrophic error from which it may be dangerous to continue, and the > > other is rebooting to recover from a non-fatal condition which the > > programmers have not bothered to handle online. >=20 > It's a matter of degree. Since the programmers haven't bothered to > handle it online, it's potentially dangerous to continue without > rebooting. Given enough effort, we could also recover from the failed > fsck. No, we're talking about runtime error recovery in response to an external error versus unimplemented system functionality which can be fixed by making the system more complete. We're not talking about the ability for background fsck to repair different kinds of disk corruption and continue from that point on, we're talking about how to react to corruption of data obtained by running applications _before_ fsck noticed it (and possibly repaired it). I (tautologically) suggest that it's not feasible to cause all possible applications running on FreeBSD to back out reads of corrupted data once it's noticed, and retry from that point. Consider e.g. a file server which may have picked up a corrupted copy of a file due to FS corruption, cached it, and will continue to hand out that corrupted file forever. Background fsck notices the disk corruption and may even be able to repair it, but the file server continues on oblivious. There are other examples one can think of regarding application misbehaviour due to arbitrary filesystem corruption - it's a classic case of "undefined behaviour". Traditionally, applications have been allowed to trust that what they read from the filesystem has already passed fsck, and can therefore be trusted except for runtime kernel bugs which may cause new corruption. Softupdates provides guarantees that most of the time the FS is stable without requiring a fsck (i.e. the traditional guarantee is unchanged), but there are exceptional cases where this is not true, and applications will be started on a corrupted filesystem. These exceptional cases will be detected in the background, at which point in time the system should attempt to recover from the error rather than let the system continue in an undefined state. The only robust way to get applications to back out and reread corrupted data is to restart them all, which is equivalent to a reboot. Kris --eAbsdosE1cNLO4uF 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 iD8DBQE7AKILWry0BWjoQKURArwHAJwM7Yx31e/WWnwC3kHwjMrskwQs9ACg+EnU dofkC+S8mE7qdYA6xZxEzp8= =m39b -----END PGP SIGNATURE----- --eAbsdosE1cNLO4uF-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon May 14 20:44:57 2001 Delivered-To: freebsd-fs@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 31C8137B423; Mon, 14 May 2001 20:44:49 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.3/8.11.2) id f4F3iVI45699; Mon, 14 May 2001 20:44:31 -0700 (PDT) (envelope-from dillon) Date: Mon, 14 May 2001 20:44:31 -0700 (PDT) From: Matt Dillon Message-Id: <200105150344.f4F3iVI45699@earth.backplane.com> To: Kris Kennaway Cc: Greg Lehey , Kris Kennaway , Terry Lambert , Kirk McKusick , Mikhail Teterin , cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, Ruslan Ermilov , fs@FreeBSD.ORG Subject: Re: [kris@obsecurity.org: Re: cvs commit: src/etc rc] References: <200105132342.QAA21879@beastie.mckusick.com> <200105142334.QAA05923@usr06.primenet.com> <20010515115630.H59553@wantadilla.lemis.com> <20010514193332.A85465@xor.obsecurity.org> <20010515120558.M59553@wantadilla.lemis.com> <20010514202707.B93481@xor.obsecurity.org> Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have to say, just IMHO, that as much as I like the concept of a background fsck, I will never ever in my life use the feature. I'll use the snapshots, definitely. But not the background fsck. It is plain and simply too dangerous, *especially* on large partitions where one has a lot to lose if something goes wrong. UFS just isn't designed to be able to guarentee recovery, even if softupdates can't fail theoretically. We would need a log or journal to reach the safety factor that something like XFS or ReiserFS can theoretically achieve. I welcome Kirk's addition of the feature, but I have to say that, IMHO, the *default* should not be to background fsck. The default should be to remain safe and foreground fsck. If I have a huge partition that I intend to store a database in (for example), then judicious use of newfs's -c and -i options is sufficient to reduce fsck times. Ultimately I believe that as storage systems get larger, the only safe solution is going to be replicated, distributed, quorum-based transactional filesystems. That way if a node goes down, it doesn't matter if it takes an hour to validate itself before coming back up. RAID-XYZ doesn't hack it -- it's still vulnerable to filesystem corruption due to software. Having written a database that does this sort of replication (in a read-write transactional environment), I've become a great believer in it and I think it is the only future for storing huge amounts of data. I think it is possible to solve the slow-write problem (needing a quorum to commit a write) through the use of a client-side cache, similar to what NFS does (note: I haven't done this for my database yet, but I can see how it could be done for a filesystem). It gives me great peace of mind to know that I can pull the plug on an entire colocation site and have the realtime users of our product NOT notice that it happened. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon May 14 20:59:36 2001 Delivered-To: freebsd-fs@freebsd.org Received: from winston.osd.bsdi.com (adsl-64-173-15-98.dsl.sntc01.pacbell.net [64.173.15.98]) by hub.freebsd.org (Postfix) with ESMTP id 526E437B422; Mon, 14 May 2001 20:59:19 -0700 (PDT) (envelope-from jkh@osd.bsdi.com) Received: from localhost (jkh@localhost [127.0.0.1]) by winston.osd.bsdi.com (8.11.3/8.11.2) with ESMTP id f4F3wa332029; Mon, 14 May 2001 20:58:37 -0700 (PDT) (envelope-from jkh@osd.bsdi.com) To: dillon@earth.backplane.com Cc: kris@obsecurity.org, grog@lemis.com, tlambert@primenet.com, mckusick@mckusick.com, mi@misha.privatelabs.com, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, ru@FreeBSD.org, fs@FreeBSD.org Subject: Re: [kris@obsecurity.org: Re: cvs commit: src/etc rc] In-Reply-To: <200105150344.f4F3iVI45699@earth.backplane.com> References: <20010515120558.M59553@wantadilla.lemis.com> <20010514202707.B93481@xor.obsecurity.org> <200105150344.f4F3iVI45699@earth.backplane.com> X-Mailer: Mew version 1.94.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010514205836B.jkh@osd.bsdi.com> Date: Mon, 14 May 2001 20:58:36 -0700 From: Jordan Hubbard X-Dispatcher: imput version 20000228(IM140) Lines: 15 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org From: Matt Dillon Subject: Re: [kris@obsecurity.org: Re: cvs commit: src/etc rc] Date: Mon, 14 May 2001 20:44:31 -0700 (PDT) > I have to say, just IMHO, that as much as I like the concept of a > background fsck, I will never ever in my life use the feature. I'll Well, there are fscks and there are fscks. It's my impression that *all* a background fsck on a snapshot will ever do is return free blocks to the freelist. That's it. It won't do any one of the dozens of other crazy things you've probably seen fsck do in cleaning up a badly scrogged filesystem and hence your fear, unless I'm smoking some unusually strong crack, is likely unwarranted. - JKordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon May 14 21: 8:43 2001 Delivered-To: freebsd-fs@freebsd.org Received: from mail.viasoft.com.cn (unknown [61.153.1.177]) by hub.freebsd.org (Postfix) with ESMTP id 3862137B424; Mon, 14 May 2001 21:08:30 -0700 (PDT) (envelope-from bsddiy@163.net) Received: from William ([192.168.1.98]) by mail.viasoft.com.cn (8.9.3/8.9.3) with ESMTP id MAA13554; Tue, 15 May 2001 12:06:02 +0800 Date: Tue, 15 May 2001 12:12:16 +0800 From: David Xu X-Mailer: The Bat! (v1.48f) Personal Reply-To: bsddiy@163.net Organization: Viasoft X-Priority: 3 (Normal) Message-ID: <1029181302.20010515121216@163.net> To: Matt Dillon Cc: Kris Kennaway , Greg Lehey , Terry Lambert , Kirk McKusick , Mikhail Teterin , , , Ruslan Ermilov , Subject: Re[2]: [kris@obsecurity.org: Re: cvs commit: src/etc rc] In-reply-To: <200105150344.f4F3iVI45699@earth.backplane.com> References: <200105132342.QAA21879@beastie.mckusick.com> <200105142334.QAA05923@usr06.primenet.com> <20010515115630.H59553@wantadilla.lemis.com> <20010514193332.A85465@xor.obsecurity.org> <20010515120558.M59553@wantadilla.lemis.com> <20010514202707.B93481@xor.obsecurity.org> <200105150344.f4F3iVI45699@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello Matt, Tuesday, May 15, 2001, 11:44:31 AM, you wrote: MD> I have to say, just IMHO, that as much as I like the concept of a MD> background fsck, I will never ever in my life use the feature. I'll MD> use the snapshots, definitely. But not the background fsck. It MD> is plain and simply too dangerous, *especially* on large partitions where MD> one has a lot to lose if something goes wrong. UFS just isn't designed MD> to be able to guarentee recovery, even if softupdates can't fail MD> theoretically. We would need a log or journal to reach the safety MD> factor that something like XFS or ReiserFS can theoretically achieve. Yes, I don't like background fsck too, it is too diffcult to manage, I'll turn it off on my machine. a nice solution is a journal file system. when will FreeBSD have a journal file system? -- Regards, David Xu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon May 14 21:14:36 2001 Delivered-To: freebsd-fs@freebsd.org Received: from mail.viasoft.com.cn (unknown [61.153.1.177]) by hub.freebsd.org (Postfix) with ESMTP id CAE9637B424; Mon, 14 May 2001 21:14:24 -0700 (PDT) (envelope-from bsddiy@163.net) Received: from William ([192.168.1.98]) by mail.viasoft.com.cn (8.9.3/8.9.3) with ESMTP id MAA13620; Tue, 15 May 2001 12:13:09 +0800 Date: Tue, 15 May 2001 12:19:24 +0800 From: David Xu X-Mailer: The Bat! (v1.48f) Personal Reply-To: bsddiy@163.net Organization: Viasoft X-Priority: 3 (Normal) Message-ID: <1549608986.20010515121924@163.net> To: Kris Kennaway Cc: Greg Lehey , Terry Lambert , Kirk McKusick , Mikhail Teterin , , , Ruslan Ermilov , Subject: Re[2]: [kris@obsecurity.org: Re: cvs commit: src/etc rc] In-reply-To: <20010514202707.B93481@xor.obsecurity.org> References: <200105132342.QAA21879@beastie.mckusick.com> <200105142334.QAA05923@usr06.primenet.com> <20010515115630.H59553@wantadilla.lemis.com> <20010514193332.A85465@xor.obsecurity.org> <20010515120558.M59553@wantadilla.lemis.com> <20010514202707.B93481@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello Kris, Tuesday, May 15, 2001, 11:27:07 AM, you wrote: KK> These exceptional cases will be detected in the background, at which KK> point in time the system should attempt to recover from the error KK> rather than let the system continue in an undefined state. The only KK> robust way to get applications to back out and reread corrupted data KK> is to restart them all, which is equivalent to a reboot. KK> Kris how about if your server application has already sent out corrupted data to your client? how to let your client application restart? client may have already committed a transaction according your corrupted price and goods have already been sent out to your customer, how do you let them back to your shop? -- Regards, David Xu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon May 14 21:17:37 2001 Delivered-To: freebsd-fs@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-32.dsl.lsan03.pacbell.net [63.207.60.32]) by hub.freebsd.org (Postfix) with ESMTP id D445E37B42C; Mon, 14 May 2001 21:17:28 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id B0FCF66C8C; Mon, 14 May 2001 21:17:27 -0700 (PDT) Date: Mon, 14 May 2001 21:17:27 -0700 From: Kris Kennaway To: Jordan Hubbard Cc: dillon@earth.backplane.com, kris@obsecurity.org, grog@lemis.com, tlambert@primenet.com, mckusick@mckusick.com, mi@misha.privatelabs.com, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, ru@FreeBSD.org, fs@FreeBSD.org Subject: Re: [kris@obsecurity.org: Re: cvs commit: src/etc rc] Message-ID: <20010514211727.A94708@xor.obsecurity.org> References: <20010515120558.M59553@wantadilla.lemis.com> <20010514202707.B93481@xor.obsecurity.org> <200105150344.f4F3iVI45699@earth.backplane.com> <20010514205836B.jkh@osd.bsdi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="fdj2RfSjLxBAspz7" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010514205836B.jkh@osd.bsdi.com>; from jkh@osd.bsdi.com on Mon, May 14, 2001 at 08:58:36PM -0700 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 14, 2001 at 08:58:36PM -0700, Jordan Hubbard wrote: > From: Matt Dillon > Subject: Re: [kris@obsecurity.org: Re: cvs commit: src/etc rc] > Date: Mon, 14 May 2001 20:44:31 -0700 (PDT) >=20 > > I have to say, just IMHO, that as much as I like the concept of a > > background fsck, I will never ever in my life use the feature. I'll >=20 > Well, there are fscks and there are fscks. It's my impression that > *all* a background fsck on a snapshot will ever do is return free > blocks to the freelist. That's it. It won't do any one of the dozens > of other crazy things you've probably seen fsck do in cleaning up a > badly scrogged filesystem and hence your fear, unless I'm smoking some > unusually strong crack, is likely unwarranted. I think thats all it does at the moment -- we started out talking about how to make it barf acceptibly if it found something more, and then someone raised the question of "what if we could make the background fsck process recover from a wider class of errors" (by improving fsck, or rerunning a foreground fsck on the ro volume, etc), to which Terry pointed out that it's still not enough to ensure consistency of the already running system. Kris --fdj2RfSjLxBAspz7 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 iD8DBQE7AK3WWry0BWjoQKURAlqpAKCqmWai6hTKO22IUwaFbLSiuvebLACgvEb+ isyAfKUn1XLLT/VQFAIK420= =22/G -----END PGP SIGNATURE----- --fdj2RfSjLxBAspz7-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon May 14 22:21:23 2001 Delivered-To: freebsd-fs@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id D591837B449; Mon, 14 May 2001 22:21:17 -0700 (PDT) (envelope-from billf@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1098) id 5296B81D06; Tue, 15 May 2001 00:21:07 -0500 (CDT) Date: Tue, 15 May 2001 00:21:07 -0500 From: Bill Fumerola To: David Xu Cc: Kris Kennaway , cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: [kris@obsecurity.org: Re: cvs commit: src/etc rc] Message-ID: <20010515002107.M37979@elvis.mu.org> References: <200105132342.QAA21879@beastie.mckusick.com> <200105142334.QAA05923@usr06.primenet.com> <20010515115630.H59553@wantadilla.lemis.com> <20010514193332.A85465@xor.obsecurity.org> <20010515120558.M59553@wantadilla.lemis.com> <20010514202707.B93481@xor.obsecurity.org> <1549608986.20010515121924@163.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1549608986.20010515121924@163.net>; from bsddiy@163.net on Tue, May 15, 2001 at 12:19:24PM +0800 X-Operating-System: FreeBSD 4.3-FEARSOME-20010328 i386 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, May 15, 2001 at 12:19:24PM +0800, David Xu wrote: > how about if your server application has already sent out corrupted > data to your client? how to let your client application restart? > client may have already committed a transaction according your > corrupted price and goods have already been sent out to your customer, > how do you let them back to your shop? what about fairings? doesn't background fsck not take them into account? -- Bill Fumerola - security yahoo / Yahoo! inc. - fumerola@yahoo-inc.com / billf@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon May 14 22:24:33 2001 Delivered-To: freebsd-fs@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-32.dsl.lsan03.pacbell.net [63.207.60.32]) by hub.freebsd.org (Postfix) with ESMTP id 99A4037B422; Mon, 14 May 2001 22:24:23 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 1EC0666C8C; Mon, 14 May 2001 22:24:23 -0700 (PDT) Date: Mon, 14 May 2001 22:24:23 -0700 From: Kris Kennaway To: David Xu Cc: Kris Kennaway , Greg Lehey , Terry Lambert , Kirk McKusick , Mikhail Teterin , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, Ruslan Ermilov , fs@FreeBSD.org Subject: Re: [kris@obsecurity.org: Re: cvs commit: src/etc rc] Message-ID: <20010514222422.B95631@xor.obsecurity.org> References: <200105132342.QAA21879@beastie.mckusick.com> <200105142334.QAA05923@usr06.primenet.com> <20010515115630.H59553@wantadilla.lemis.com> <20010514193332.A85465@xor.obsecurity.org> <20010515120558.M59553@wantadilla.lemis.com> <20010514202707.B93481@xor.obsecurity.org> <1549608986.20010515121924@163.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="z6Eq5LdranGa6ru8" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1549608986.20010515121924@163.net>; from bsddiy@163.net on Tue, May 15, 2001 at 12:19:24PM +0800 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --z6Eq5LdranGa6ru8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, May 15, 2001 at 12:19:24PM +0800, David Xu wrote: > how about if your server application has already sent out corrupted > data to your client? how to let your client application restart? > client may have already committed a transaction according your > corrupted price and goods have already been sent out to your customer, > how do you let them back to your shop? Ultimately there are limits to every piece of technology. Let's not go overboard here with the prophecies of doom. Kris --z6Eq5LdranGa6ru8 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 iD8DBQE7AL2GWry0BWjoQKURAkY4AJ9U0zPKjnoHPxxEL4Lkr5mVYWMC/wCg/PBT qwN22HxCSRQyWhgQuqxq594= =LDoI -----END PGP SIGNATURE----- --z6Eq5LdranGa6ru8-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon May 14 22:56:42 2001 Delivered-To: freebsd-fs@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 11ADD37B422; Mon, 14 May 2001 22:56:34 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f4F5tY707474; Mon, 14 May 2001 22:55:34 -0700 (PDT) Date: Mon, 14 May 2001 22:55:34 -0700 From: Alfred Perlstein To: David Xu Cc: Kris Kennaway , Greg Lehey , Terry Lambert , Kirk McKusick , Mikhail Teterin , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, Ruslan Ermilov , fs@FreeBSD.org Subject: Re: Re[2]: [kris@obsecurity.org: Re: cvs commit: src/etc rc] Message-ID: <20010514225533.M2009@fw.wintelcom.net> References: <200105132342.QAA21879@beastie.mckusick.com> <200105142334.QAA05923@usr06.primenet.com> <20010515115630.H59553@wantadilla.lemis.com> <20010514193332.A85465@xor.obsecurity.org> <20010515120558.M59553@wantadilla.lemis.com> <20010514202707.B93481@xor.obsecurity.org> <1549608986.20010515121924@163.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1549608986.20010515121924@163.net>; from bsddiy@163.net on Tue, May 15, 2001 at 12:19:24PM +0800 X-all-your-base: are belong to us. Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * David Xu [010514 21:14] wrote: > > how about if your server application has already sent out corrupted > data to your client? how to let your client application restart? > client may have already committed a transaction according your > corrupted price and goods have already been sent out to your customer, > how do you let them back to your shop? 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. It will use this information to roll-back/fix any corrupted data it fetches. Or at least halt itself and scream for help. :) -- -Alfred Perlstein - [alfred@freebsd.org] http://www.egr.unlv.edu/~slumos/on-netbsd.html To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon May 14 22:59:21 2001 Delivered-To: freebsd-fs@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 346C237B424; Mon, 14 May 2001 22:59:14 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f4F5pxl07444; Mon, 14 May 2001 22:51:59 -0700 (PDT) Date: Mon, 14 May 2001 22:51:59 -0700 From: Alfred Perlstein To: David Xu Cc: Matt Dillon , Kris Kennaway , Greg Lehey , Terry Lambert , Kirk McKusick , Mikhail Teterin , cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, Ruslan Ermilov , fs@FreeBSD.ORG Subject: Re: Re[2]: [kris@obsecurity.org: Re: cvs commit: src/etc rc] Message-ID: <20010514225159.L2009@fw.wintelcom.net> References: <200105132342.QAA21879@beastie.mckusick.com> <200105142334.QAA05923@usr06.primenet.com> <20010515115630.H59553@wantadilla.lemis.com> <20010514193332.A85465@xor.obsecurity.org> <20010515120558.M59553@wantadilla.lemis.com> <20010514202707.B93481@xor.obsecurity.org> <200105150344.f4F3iVI45699@earth.backplane.com> <1029181302.20010515121216@163.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1029181302.20010515121216@163.net>; from bsddiy@163.net on Tue, May 15, 2001 at 12:12:16PM +0800 X-all-your-base: are belong to us. Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * David Xu [010514 21:09] wrote: > Hello Matt, > > Yes, I don't like background fsck too, it is too diffcult to manage, > I'll turn it off on my machine. a nice solution is a journal file > system. Really? A logging filesystem suffers from the same problems that softupdates background fsck does. Basically if you have crash because the disk suddenly starts spewing out errors those areas will remain broken even after the logging filesystem restarts. In fact it's quite possible that a logging filesystem will continue to trip over the same broken sectors unless something like Kirk's proposal is implemented, meaning a system halt followed by a "full" fsck. Of course I don't really expect you to understand any of this as you've proven pretty clue-resistant, I just mention it for the benifit of others who might be able to learn from the knowledge presented here. > when will FreeBSD have a journal file system? As soon as you, David Xu, programmer of the century implements it. bye, -- -Alfred Perlstein - [alfred@freebsd.org] Daemon News Magazine in your snail-mail! http://magazine.daemonnews.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue May 15 2:58: 8 2001 Delivered-To: freebsd-fs@freebsd.org Received: from barry.mail.mindspring.net (barry.mail.mindspring.net [207.69.200.25]) by hub.freebsd.org (Postfix) with ESMTP id B707F37B422; Tue, 15 May 2001 02:57:57 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (pool0356.cvx21-bradley.dialup.earthlink.net [209.179.193.101]) by barry.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id FAA03113; Tue, 15 May 2001 05:57:44 -0400 (EDT) Message-ID: <3B00FDA9.1203D42F@mindspring.com> Date: Tue, 15 May 2001 02:58:01 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Kris Kennaway Cc: Greg Lehey , Terry Lambert , Kirk McKusick , Mikhail Teterin , cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, Ruslan Ermilov , fs@FreeBSD.ORG Subject: Re: [kris@obsecurity.org: Re: cvs commit: src/etc rc] References: <200105132342.QAA21879@beastie.mckusick.com> <200105142334.QAA05923@usr06.primenet.com> <20010515115630.H59553@wantadilla.lemis.com> <20010514193332.A85465@xor.obsecurity.org> <20010515120558.M59553@wantadilla.lemis.com> <20010514202707.B93481@xor.obsecurity.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Kris Kennaway wrote: > These exceptional cases will be detected in the background, at which > point in time the system should attempt to recover from the error > rather than let the system continue in an undefined state. The only > robust way to get applications to back out and reread corrupted data > is to restart them all, which is equivalent to a reboot. Yes. This is a case where a System V style startup script mechanism, and/or run-levels would be useful. In the first instance, everything that is running at the current run-level can be restarted automatically by looking for the run-level (who -r), and then traversing the startup scripts, feeding them "stop" in reverse order and "start" in forward order, to get the job done. Alternately, a "restart" run level can be specified to inittab itself, and init would "just do whatever is necessary to make the system sane again". In reality, it should never get to the point where it's an issue, or it's too late anyway (I'm not going to be running background fsck on any mission critical systems, and I'm firmly in the "disable it by default" camp). On the other hand, I would not be adverse to having soft updates turned on by default, following a new install or an upgrade... it kind of needs to be a newfs option for that, though. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue May 15 3:12:29 2001 Delivered-To: freebsd-fs@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.13]) by hub.freebsd.org (Postfix) with SMTP id 9088137B423 for ; Tue, 15 May 2001 03:12:22 -0700 (PDT) (envelope-from roam@orbitel.bg) Received: (qmail 15060 invoked by uid 1000); 15 May 2001 10:11:43 -0000 Date: Tue, 15 May 2001 13:11:43 +0300 From: Peter Pentchev To: Terry Lambert Cc: Kris Kennaway , Greg Lehey , Terry Lambert , Kirk McKusick , Mikhail Teterin , cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, Ruslan Ermilov , fs@FreeBSD.ORG Subject: Re: [kris@obsecurity.org: Re: cvs commit: src/etc rc] Message-ID: <20010515131143.D11592@ringworld.oblivion.bg> Mail-Followup-To: Terry Lambert , Kris Kennaway , Greg Lehey , Terry Lambert , Kirk McKusick , Mikhail Teterin , cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, Ruslan Ermilov , fs@FreeBSD.ORG References: <200105132342.QAA21879@beastie.mckusick.com> <200105142334.QAA05923@usr06.primenet.com> <20010515115630.H59553@wantadilla.lemis.com> <20010514193332.A85465@xor.obsecurity.org> <20010515120558.M59553@wantadilla.lemis.com> <20010514202707.B93481@xor.obsecurity.org> <3B00FDA9.1203D42F@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B00FDA9.1203D42F@mindspring.com>; from tlambert2@mindspring.com on Tue, May 15, 2001 at 02:58:01AM -0700 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, May 15, 2001 at 02:58:01AM -0700, Terry Lambert wrote: [snip] > > On the other hand, I would not be adverse to having soft > updates turned on by default, following a new install or > an upgrade... it kind of needs to be a newfs option for > that, though. It is.. and in 4.3-RELEASE, the Label Editor gives you the opportunity to create the labels with soft updates turned on. G'luck, Peter -- If I were you, who would be reading this sentence? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue May 15 5:24:46 2001 Delivered-To: freebsd-fs@freebsd.org Received: from bilver.wjv.com (dhcp-1-218.n01.orldfl01.us.ra.verio.net [157.238.210.218]) by hub.freebsd.org (Postfix) with ESMTP id 0F3D437B42C; Tue, 15 May 2001 05:24:35 -0700 (PDT) (envelope-from bill@bilver.wjv.com) Received: (from bill@localhost) by bilver.wjv.com (8.11.1/8.11.1) id f4FCLfs45711; Tue, 15 May 2001 08:21:41 -0400 (EDT) (envelope-from bill) Date: Tue, 15 May 2001 08:21:41 -0400 From: Bill Vermillion To: Jordan Hubbard Cc: dillon@earth.backplane.com, kris@obsecurity.org, grog@lemis.com, tlambert@primenet.com, mckusick@mckusick.com, mi@misha.privatelabs.com, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, ru@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: [kris@obsecurity.org: Re: cvs commit: src/etc rc] Message-ID: <20010515082141.C45443@wjv.com> Reply-To: bv@wjv.com References: <20010515120558.M59553@wantadilla.lemis.com> <20010514202707.B93481@xor.obsecurity.org> <200105150344.f4F3iVI45699@earth.backplane.com> <20010514205836B.jkh@osd.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010514205836B.jkh@osd.bsdi.com>; from jkh@osd.bsdi.com on Mon, May 14, 2001 at 08:58:36PM -0700 Organization: W.J.Vermillion / Orlando - Winter Park Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, May 14, 2001 at 08:58:36PM -0700, Jordan Hubbard thus sprach: > From: Matt Dillon > Subject: Re: [kris@obsecurity.org: Re: cvs commit: src/etc rc] > Date: Mon, 14 May 2001 20:44:31 -0700 (PDT) > > I have to say, just IMHO, that as much as I like the concept > > of a background fsck, I will never ever in my life use the > > feature. I'll > Well, there are fscks and there are fscks. It's my impression that > *all* a background fsck on a snapshot will ever do is return free > blocks to the freelist. That's it. It won't do any one of the dozens > of other crazy things you've probably seen fsck do in cleaning up a > badly scrogged filesystem and hence your fear, unless I'm smoking some > unusually strong crack, is likely unwarranted. I agree. It's the 'fail-safe' approach. On older slower Sys V based 'thingys' I've worked with in the past we'd run fsck -S from cron nightly. That just rebuilt the free list IF and ONLY IF everything else was perfectly ok. -- Bill Vermillion - bv @ wjv . com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue May 15 7:36:35 2001 Delivered-To: freebsd-fs@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 8A99037B42C for ; Tue, 15 May 2001 07:36:33 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id KAA39732; Tue, 15 May 2001 10:36:21 -0400 (EDT) (envelope-from wollman) Date: Tue, 15 May 2001 10:36:21 -0400 (EDT) From: Garrett Wollman Message-Id: <200105151436.KAA39732@khavrinen.lcs.mit.edu> To: Kris Kennaway Cc: fs@FreeBSD.org Subject: Re: [kris@obsecurity.org: Re: cvs commit: src/etc rc] In-Reply-To: <20010514202707.B93481@xor.obsecurity.org> References: <200105132342.QAA21879@beastie.mckusick.com> <200105142334.QAA05923@usr06.primenet.com> <20010515115630.H59553@wantadilla.lemis.com> <20010514193332.A85465@xor.obsecurity.org> <20010515120558.M59553@wantadilla.lemis.com> <20010514202707.B93481@xor.obsecurity.org> Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > unchanged), but there are exceptional cases where this is not true, > and applications will be started on a corrupted filesystem. > These exceptional cases will be detected in the background, at which If the corruption is significant and the filesystem is active, it will often (but not always) lead to a panic fairly quickly -- perhaps even before the background fsck has run. (Recall that the background fsck has to create a snapshot before it can do anything; it's possible that the process of creating the snapshot will trip over filesystem corruption and panic the system.) -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue May 15 8: 9:36 2001 Delivered-To: freebsd-fs@freebsd.org Received: from aldan.algebra.com (aldan.algebra.com [216.254.65.224]) by hub.freebsd.org (Postfix) with ESMTP id 8A3AB37B423; Tue, 15 May 2001 08:09:29 -0700 (PDT) (envelope-from mi@aldan.algebra.com) Received: from aldan.algebra.com (localhost [127.0.0.1]) by aldan.algebra.com (8.11.3/8.11.3) with ESMTP id f4FFABt62656; Tue, 15 May 2001 11:10:14 -0400 (EDT) (envelope-from mi@aldan.algebra.com) Message-Id: <200105151510.f4FFABt62656@aldan.algebra.com> Date: Tue, 15 May 2001 11:10:08 -0400 (EDT) From: Mikhail Teterin Subject: Re: Re[2]: [kris@obsecurity.org: Re: cvs commit: src/etc rc] To: bright@wintelcom.net Cc: bsddiy@163.net, kris@obsecurity.org, grog@lemis.com, tlambert@primenet.com, mckusick@mckusick.com, ru@FreeBSD.org, fs@FreeBSD.org In-Reply-To: <20010514225533.M2009@fw.wintelcom.net> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [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. 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? -mi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue May 15 10: 3:27 2001 Delivered-To: freebsd-fs@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 3CB1B37B423; Tue, 15 May 2001 10:03:19 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.11.3/8.11.3) with ESMTP id f4FH2EA49076; Tue, 15 May 2001 13:02:14 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20010514211727.A94708@xor.obsecurity.org> References: <20010515120558.M59553@wantadilla.lemis.com> <20010514202707.B93481@xor.obsecurity.org> <200105150344.f4F3iVI45699@earth.backplane.com> <20010514205836B.jkh@osd.bsdi.com> <20010514211727.A94708@xor.obsecurity.org> Date: Tue, 15 May 2001 13:02:11 -0400 To: Kris Kennaway , Jordan Hubbard From: Garance A Drosihn Subject: Re: Discussion of Background 'fsck's (was: src/etc rc) Cc: dillon@earth.backplane.com, kris@obsecurity.org, grog@lemis.com, tlambert@primenet.com, mckusick@mckusick.com, mi@misha.privatelabs.com, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, ru@FreeBSD.org, fs@FreeBSD.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 9:17 PM -0700 5/14/01, Kris Kennaway wrote: >On Mon, May 14, 2001 at 08:58:36PM -0700, Jordan Hubbard wrote: > > From: Matt Dillon This discussion on background 'fsck's is fascinating and it has a good deal of interesting info in it. Could we have a SUBJECT that at least vaguely indicated what the topic is about? Six months from now, few people will remember that the "subject" was Re: [kris@obsecurity.org: Re: cvs commit: src/etc rc] -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue May 15 10: 9:45 2001 Delivered-To: freebsd-fs@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 76E1D37B424; Tue, 15 May 2001 10:09:39 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.3/8.11.2) id f4FH9XB53717; Tue, 15 May 2001 10:09:33 -0700 (PDT) (envelope-from dillon) Date: Tue, 15 May 2001 10:09:33 -0700 (PDT) From: Matt Dillon Message-Id: <200105151709.f4FH9XB53717@earth.backplane.com> To: Jordan Hubbard Cc: kris@obsecurity.org, grog@lemis.com, tlambert@primenet.com, mckusick@mckusick.com, mi@misha.privatelabs.com, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, ru@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: [kris@obsecurity.org: Re: cvs commit: src/etc rc] References: <20010515120558.M59553@wantadilla.lemis.com> <20010514202707.B93481@xor.obsecurity.org> <200105150344.f4F3iVI45699@earth.backplane.com> <20010514205836B.jkh@osd.bsdi.com> Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org : :From: Matt Dillon :Subject: Re: [kris@obsecurity.org: Re: cvs commit: src/etc rc] :Date: Mon, 14 May 2001 20:44:31 -0700 (PDT) : :> I have to say, just IMHO, that as much as I like the concept of a :> background fsck, I will never ever in my life use the feature. I'll : :Well, there are fscks and there are fscks. It's my impression that :*all* a background fsck on a snapshot will ever do is return free :blocks to the freelist. That's it. It won't do any one of the dozens :of other crazy things you've probably seen fsck do in cleaning up a :badly scrogged filesystem and hence your fear, unless I'm smoking some :unusually strong crack, is likely unwarranted. : :- JKordan The problem isn't what the background fsck does... it's what happens when a corrupted filesystem is mounted r/w and you only find out later that fsck couldn't handle it. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue May 15 10:47:17 2001 Delivered-To: freebsd-fs@freebsd.org Received: from proxon.bnc.net (proxon.bnc.net [62.225.99.6]) by hub.freebsd.org (Postfix) with ESMTP id 9160937B42C for ; Tue, 15 May 2001 10:47:14 -0700 (PDT) (envelope-from noses@proxon.bnc.net) Received: (from noses@localhost) by proxon.bnc.net (8.11.3/8.11.3) id f4FHl7N06711; Tue, 15 May 2001 19:47:07 +0200 (CEST) (envelope-from noses) Date: Tue, 15 May 2001 19:47:07 +0200 (CEST) Message-Id: <200105151747.f4FHl7N06711@proxon.bnc.net> From: Noses To: fs@freebsd.org Subject: (fwd) Re: Re[2]: [kris@obsecurity.org: Re: cvs commit: src/etc rc] Organization: Noses' cave User-Agent: tin/1.5.6-20000803 ("Dust") (UNIX) (FreeBSD/4.3-STABLE (i386)) Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org So spoke mi@aldan.algebra.com (Mikhail Teterin): >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. > >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? Well... Once upon a time there was a major German online service provider (I refuse calling this kind of service ISP) who ran their accounting database on a faily new fairly big Sun E10K with lots of online storage behind it (millions of accounting records per day take some space). Only after recycling the oldest backup tapes someone noticed complete database corruption - caused by a broken SCSI driver writing nonesense to the disk. So much about "serious production quality OS"es. The only OS without any serious problems of this kind I've ever had was Tandem's Nonstop kernel and I'm sure I was just lucky. Noses. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue May 15 11:17:43 2001 Delivered-To: freebsd-fs@freebsd.org Received: from privatecube.privatelabs.com (privatecube.privatelabs.com [63.114.185.254]) by hub.freebsd.org (Postfix) with ESMTP id 6F0B137B422; Tue, 15 May 2001 11:17:40 -0700 (PDT) (envelope-from mi@aldan.algebra.com) Received: from misha.privatelabs.com (root@misha.plten [10.0.0.106]) by privatecube.privatelabs.com (8.9.3/8.9.2) with ESMTP id NAA26739; Tue, 15 May 2001 13:38:15 -0400 From: mi@aldan.algebra.com Received: from misha.privatelabs.com (mi@localhost [127.0.0.1]) by misha.privatelabs.com (8.11.3/8.11.1) with ESMTP id f4FIHHr26893; Tue, 15 May 2001 14:17:18 -0400 (EDT) (envelope-from mi@aldan.algebra.com) Message-Id: <200105151817.f4FIHHr26893@misha.privatelabs.com> Date: Tue, 15 May 2001 14:17:16 -0400 (EDT) Reply-To: mi@aldan.algebra.com Subject: Re: background fsck and rebooting To: dillon@earth.backplane.com Cc: jkh@osd.bsdi.com, kris@obsecurity.org, grog@lemis.com, tlambert@primenet.com, mckusick@mckusick.com, ru@FreeBSD.ORG, fs@FreeBSD.ORG In-Reply-To: <200105151709.f4FH9XB53717@earth.backplane.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [cvs lists taken off the CC] After a second thought, Terry's note, that the reboot IS necessary to ensure, that some files read from the damaged file-system are not corrupted (even if the background fsck succeeds), does not make that much sense to me: . there is an obvious race between those files being read and the reboot time; . as someone else pointed out, we can not restart (or even alert) non-local consumers of the corrupted data (clients) anyway. The above two reasons, IMHO, indicate, that the background fsck should NOT be on by default. Enabling it should be a mount option, and the potential for the troubles should be well documented. Now, to speed up startups, may be, we can mount the filesystems immediately, but hang all read/write attempts until the background fsck is over? This will let programs start, but not run until their data is ready. -mi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue May 15 11:18:14 2001 Delivered-To: freebsd-fs@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id CE6C837B42C; Tue, 15 May 2001 11:18:05 -0700 (PDT) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.9.3/8.9.3) id LAA06717; Tue, 15 May 2001 11:10:26 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp02.primenet.com, id smtpdAAArYaOan; Tue May 15 11:10:17 2001 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id LAA28967; Tue, 15 May 2001 11:19:07 -0700 (MST) From: Terry Lambert Message-Id: <200105151819.LAA28967@usr08.primenet.com> Subject: Re: [kris@obsecurity.org: Re: cvs commit: src/etc rc] To: bv@wjv.com Date: Tue, 15 May 2001 18:19:07 +0000 (GMT) Cc: jkh@osd.bsdi.com (Jordan Hubbard), dillon@earth.backplane.com, kris@obsecurity.org, grog@lemis.com, tlambert@primenet.com, mckusick@mckusick.com, mi@misha.privatelabs.com, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, ru@FreeBSD.ORG, fs@FreeBSD.ORG In-Reply-To: <20010515082141.C45443@wjv.com> from "Bill Vermillion" at May 15, 2001 08:21:41 AM 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-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > I have to say, just IMHO, that as much as I like the concept > > > of a background fsck, I will never ever in my life use the > > > feature. I'll > > > Well, there are fscks and there are fscks. It's my impression that > > *all* a background fsck on a snapshot will ever do is return free > > blocks to the freelist. That's it. It won't do any one of the dozens > > of other crazy things you've probably seen fsck do in cleaning up a > > badly scrogged filesystem and hence your fear, unless I'm smoking some > > unusually strong crack, is likely unwarranted. > > I agree. It's the 'fail-safe' approach. On older slower Sys V > based 'thingys' I've worked with in the past we'd run > fsck -S from cron nightly. That just rebuilt the free list IF and > ONLY IF everything else was perfectly ok. We would all be much better served by implementing soft read-only; Kirk and Julian and I have discussed this on several occsions; I believe the BSDI version of the code has this, as did the version of the code Matt Day did when he, Mark Muhlestein, Steve Labelle, and I ported the Heidemann framework and FFS and UFS to Windows 95. 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-fs" in the body of the message From owner-freebsd-fs Tue May 15 11:22:52 2001 Delivered-To: freebsd-fs@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-32.dsl.lsan03.pacbell.net [63.207.60.32]) by hub.freebsd.org (Postfix) with ESMTP id 0C3B037B424; Tue, 15 May 2001 11:22:48 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 500FA66D87; Tue, 15 May 2001 11:22:47 -0700 (PDT) Date: Tue, 15 May 2001 11:22:47 -0700 From: Kris Kennaway To: Mikhail Teterin 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> References: <20010514225533.M2009@fw.wintelcom.net> <200105151510.f4FFABt62656@aldan.algebra.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="LpQ9ahxlCli8rRTG" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200105151510.f4FFABt62656@aldan.algebra.com>; from mi@aldan.algebra.com on Tue, May 15, 2001 at 11:10:08AM -0400 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --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 From owner-freebsd-fs Tue May 15 11:30:10 2001 Delivered-To: freebsd-fs@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id 326CF37B422; Tue, 15 May 2001 11:30:07 -0700 (PDT) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id LAA25358; Tue, 15 May 2001 11:20:31 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp04.primenet.com, id smtpdAAAUsaGnX; Tue May 15 11:20:05 2001 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id LAA29042; Tue, 15 May 2001 11:21:06 -0700 (MST) From: Terry Lambert Message-Id: <200105151821.LAA29042@usr08.primenet.com> Subject: Re: Re[2]: [kris@obsecurity.org: Re: cvs commit: src/etc rc] To: mi@aldan.algebra.com (Mikhail Teterin) Date: Tue, 15 May 2001 18:21:05 +0000 (GMT) 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 In-Reply-To: <200105151510.f4FFABt62656@aldan.algebra.com> from "Mikhail Teterin" at May 15, 2001 11:10:08 AM 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-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > 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. > > 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? Because there are implied dependencies between data and the indices which refer to it, about which the host operating system can't have any information, unless it exports a transactioning system to user space, and the database vendor adopts that interface. 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-fs" in the body of the message From owner-freebsd-fs Tue May 15 12:26:33 2001 Delivered-To: freebsd-fs@freebsd.org Received: from taku.hut.fi (taku.hut.fi [130.233.228.87]) by hub.freebsd.org (Postfix) with ESMTP id 75C2F37B42C for ; Tue, 15 May 2001 12:26:27 -0700 (PDT) (envelope-from sparvu@alpha.hut.fi) Received: from alpha.hut.fi (sparvu@alpha.hut.fi [130.233.224.50]) by taku.hut.fi (8.9.3/8.9.3) with ESMTP id WAA32399; Tue, 15 May 2001 22:26:20 +0300 (EET DST) Date: Tue, 15 May 2001 22:26:20 +0300 (EET DST) From: Stefan Parvu To: freebsd-fs@freebsd.org Cc: fbsdq@yahoo.com Subject: UFS to FAT32 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, I tested FreeBSD 4.3-RELEASE doing this : 1. mount /win98 partition as rw only. Move from BSD partition to FAT32 a file of 500MB. Time around 25min. System really slow. CPU as idle around 99% but vmstat reported a lot of blocked processes(2to6). Can't work anymore in the box until de copy operation finished. 2. mount /win98 as rw, sync. The same scenario movinf a file 500MB from UFS to FAT32 . Time around 35min. System ok. You can do some other work meanwhile copy operation. In the first scenario there were really long delays until opening a new terminal, or top, whatever processes. So why is happening this ? Should /win98 be mounted a sync option. In both cases I used an ad0: 19470MB [39560/16/63] at ata0-master UDMA33 Pentium III 550MHz 128MBRAM, 500swap. Thanks, Stefan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue May 15 13:39:56 2001 Delivered-To: freebsd-fs@freebsd.org Received: from hotmail.com (f56.law4.hotmail.com [216.33.149.56]) by hub.freebsd.org (Postfix) with ESMTP id 5BDC837B422; Tue, 15 May 2001 13:39:49 -0700 (PDT) (envelope-from messiah_man@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 15 May 2001 13:39:49 -0700 Received: from 62.242.79.117 by lw4fd.law4.hotmail.msn.com with HTTP; Tue, 15 May 2001 20:39:49 GMT X-Originating-IP: [62.242.79.117] From: "Munish Chopra" To: freebsd-stable@freebsd.org, freebsd-fs@freebsd.org Subject: Status of NTFS write-support Date: Tue, 15 May 2001 22:39:49 +0200 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 15 May 2001 20:39:49.0272 (UTC) FILETIME=[2F6E5980:01C0DD7F] Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I've got a dual boot 4.3-STABLE and Win2k. I'm mounting my Win2k drive from FreeBSD, but I've been wondering about writing to it (reading is fine). The docs are a bit foggy, so I wanted to know whether writing to NTFS volumes is fine or whether it's giving problems. Anyone with experiences in this area? Cheers, Munish _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue May 15 17:38:55 2001 Delivered-To: freebsd-fs@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 5E2BD37B423 for ; Tue, 15 May 2001 17:38:46 -0700 (PDT) (envelope-from grog@lemis.com) Received: by wantadilla.lemis.com (Postfix, from userid 1004) id A82896ACBC; Wed, 16 May 2001 10:08:44 +0930 (CST) Date: Wed, 16 May 2001 10:08:44 +0930 From: Greg Lehey To: Noses Cc: fs@freebsd.org Subject: Database integrity (was .*: cvs commit: src/etc rc) Message-ID: <20010516100844.K59553@wantadilla.lemis.com> References: <200105151747.f4FHl7N06711@proxon.bnc.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200105151747.f4FHl7N06711@proxon.bnc.net>; from noses@noses.com on Tue, May 15, 2001 at 07:47:07PM +0200 Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tuesday, 15 May 2001 at 19:47:07 +0200, Noses wrote: > So spoke mi@aldan.algebra.com (Mikhail Teterin): >> 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. >> >> 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? > > Well... Once upon a time there was a major German online service provider (I > refuse calling this kind of service ISP) who ran their accounting database > on a faily new fairly big Sun E10K with lots of online storage behind it > (millions of accounting records per day take some space). Only after > recycling the oldest backup tapes someone noticed complete database > corruption - caused by a broken SCSI driver writing nonesense to the disk. > > So much about "serious production quality OS"es. The only OS without any > serious problems of this kind I've ever had was Tandem's Nonstop kernel and > I'm sure I was just lucky. You were just lucky. I've seen unbelievable corruption in NSK. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed May 16 2:58:36 2001 Delivered-To: freebsd-fs@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 8777937B422 for ; Wed, 16 May 2001 02:58:32 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id TAA01170; Wed, 16 May 2001 19:58:23 +1000 Date: Wed, 16 May 2001 19:57:05 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Stefan Parvu Cc: freebsd-fs@FreeBSD.ORG, fbsdq@yahoo.com Subject: Re: UFS to FAT32 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 15 May 2001, Stefan Parvu wrote: > I tested FreeBSD 4.3-RELEASE doing this : > > 1. mount /win98 partition as rw only. Move from BSD partition to FAT32 a > file of 500MB. Time around 25min. System really slow. CPU as idle around > 99% but vmstat reported a lot of blocked processes(2to6). Can't work > anymore in the box until de copy operation finished. This is probably caused by new (in 4.3) default of write caching turned off for ATA drives. I'm not sure why it blocks so many processes. It should only make the system unusable when many processes other than the copy hog want to access the disk :-]. > 2. mount /win98 as rw, sync. The same scenario movinf a file 500MB from > UFS to FAT32 . Time around 35min. System ok. You can do some other work > meanwhile copy operation. In the first scenario there were really long > delays until opening a new terminal, or top, whatever processes. Interesting. The sync mount option make all writes of data blocks to the disk synchronous. It has no effect on the synchronicity of writes of metadata blocks at least for ffs, which is not where the writes are here, but msdosfs shouldn't be much different. (A quick check shows that FAT updates are not properly synced by default, but the sync option bogusly fixes this -- the sync option is only supposed to affect data writes. Syncing of the FAT should default to on and be controlled by the (currently unimplemented for msdosfs) async mount option. The only other related brokenness seems to be that the sync option doesn't give syncing of new data blocks in extendfile().) Anyway, the sync mount option is usually just a pessimization. It must be reducing the long delays by reducing the size of the average i/o. With the sync option, the system writes data blocks immediately, with a block size identical to the filesystem block size. Without it, blocks are clustered, and the average block size seen by the driver should be close to its maximum (128K for ATA disks) since the file is large. Writing a 128K block doesn't take all that long since your disk has a bandwidth of 20+-37MB/sec, but it is apparently too long to suit the clustering code. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed May 16 6:17: 1 2001 Delivered-To: freebsd-fs@freebsd.org Received: from taku.hut.fi (taku.hut.fi [130.233.228.87]) by hub.freebsd.org (Postfix) with ESMTP id 9327737B423 for ; Wed, 16 May 2001 06:16:58 -0700 (PDT) (envelope-from sparvu@alpha.hut.fi) Received: from alpha.hut.fi (sparvu@alpha.hut.fi [130.233.224.50]) by taku.hut.fi (8.9.3/8.9.3) with ESMTP id QAA05958; Wed, 16 May 2001 16:16:51 +0300 (EET DST) Date: Wed, 16 May 2001 16:16:51 +0300 (EET DST) From: Stefan Parvu To: Bruce Evans Cc: freebsd-fs@FreeBSD.ORG, fbsdq@yahoo.com Subject: Re: UFS to FAT32 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Thank you very much for email. Well I will keep some testing related with FFS and comparing the resulkt vs Solaris. Can I turn on the write cache for ATA from sysctl I think ? Are in 4.3-RELEASE softupdates integrated for fast and lot of improvements? Like OpenBSD 2.9 has announced big improvements around 60x times faster IO operations ? Another question is: Do we plan to add -async for mount_msdos ? stefan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed May 16 7: 6:11 2001 Delivered-To: freebsd-fs@freebsd.org Received: from nebula.cybercable.fr (d189.dhcp212-126.cybercable.fr [212.198.126.189]) by hub.freebsd.org (Postfix) with ESMTP id B94FC37B422 for ; Wed, 16 May 2001 07:06:07 -0700 (PDT) (envelope-from mux@qualys.com) Received: (from mux@localhost) by nebula.cybercable.fr (8.11.3/8.11.3) id f4GE64k14368; Wed, 16 May 2001 16:06:04 +0200 (CEST) (envelope-from mux) Date: Wed, 16 May 2001 16:06:03 +0200 From: Maxime Henrion To: freebsd-fs@freebsd.org Cc: Stefan Parvu Subject: Re: UFS to FAT32 Message-ID: <20010516160603.A7637@nebula.cybercable.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from sparvu@cc.hut.fi on Wed, May 16, 2001 at 04:16:51PM +0300 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Stefan Parvu wrote: > > Thank you very much for email. Well I will keep some testing related with > FFS and comparing the resulkt vs Solaris. > > Can I turn on the write cache for ATA from sysctl I think ? It's a loader tunable. You will have to add hw.ata.wc="1" to your /boot/loader.conf file. > Are in 4.3-RELEASE softupdates integrated for fast and lot of > improvements? Like OpenBSD 2.9 has announced big > improvements around 60x times faster IO operations ? Softupdates are integrated in FreeBSD for a while now. Since 4.3-RELEASE, there is a new newfs options which allows you to activate stoftupdates while formatting your partition. This is used in sysinstall to allow people to activate softupdates at the installation. The improvements in OpenBSD 2.9 are due to the new dirpref() code which has also been implemented in FreeBSD by McKusick a little before. > Another question is: Do we plan to add -async for mount_msdos ? No idea. > stefan Maxime -- Don't be fooled by cheap finnish imitations ; BSD is the One True Code Key fingerprint = F9B6 1D5A 4963 331C 88FC CA6A AB50 1EF2 8CBE 99D6 Public Key : http://www.epita.fr/~henrio_m/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed May 16 7:38:28 2001 Delivered-To: freebsd-fs@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 16C7537B42C for ; Wed, 16 May 2001 07:38:22 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id AAA22023; Thu, 17 May 2001 00:38:03 +1000 Date: Thu, 17 May 2001 00:36:45 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Maxime Henrion Cc: freebsd-fs@FreeBSD.ORG, Stefan Parvu Subject: Re: UFS to FAT32 In-Reply-To: <20010516160603.A7637@nebula.cybercable.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 16 May 2001, Maxime Henrion wrote: > Stefan Parvu wrote: > The improvements in OpenBSD 2.9 are due to the new dirpref() code which > has also been implemented in FreeBSD by McKusick a little before. However, this is not in FreeBSD 4.3. > > Another question is: Do we plan to add -async for mount_msdos ? > > No idea. Not soon. Not writing the FAT by default gives half of the advantages and most of the disadvantages of -async. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed May 16 12:25:48 2001 Delivered-To: freebsd-fs@freebsd.org Received: from taku.hut.fi (taku.hut.fi [130.233.228.87]) by hub.freebsd.org (Postfix) with ESMTP id 40F2237B422 for ; Wed, 16 May 2001 12:25:45 -0700 (PDT) (envelope-from sparvu@alpha.hut.fi) Received: from alpha.hut.fi (sparvu@alpha.hut.fi [130.233.224.50]) by taku.hut.fi (8.9.3/8.9.3) with ESMTP id WAA03031; Wed, 16 May 2001 22:25:33 +0300 (EET DST) Date: Wed, 16 May 2001 22:25:33 +0300 (EET DST) From: Stefan Parvu To: Bruce Evans Cc: Maxime Henrion , freebsd-fs@FreeBSD.ORG, Stefan Parvu Subject: Re: UFS to FAT32 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Then do I need to cvsup to -CURRENT or how ? By the way how can I cvsup to 5.0_CURRENT ? I think there I could find setfacle /getfacl and softupdates integrated ? > > The improvements in OpenBSD 2.9 are due to the new dirpref() code which > > has also been implemented in FreeBSD by McKusick a little before. > > However, this is not in FreeBSD 4.3. On Thu, 17 May 2001, Bruce Evans wrote: > Date: Thu, 17 May 2001 00:36:45 +1000 (EST) > From: Bruce Evans > To: Maxime Henrion > Cc: freebsd-fs@FreeBSD.ORG, Stefan Parvu > Subject: Re: UFS to FAT32 > > On Wed, 16 May 2001, Maxime Henrion wrote: > > > Stefan Parvu wrote: > > > The improvements in OpenBSD 2.9 are due to the new dirpref() code which > > has also been implemented in FreeBSD by McKusick a little before. > > However, this is not in FreeBSD 4.3. > > > > Another question is: Do we plan to add -async for mount_msdos ? > > > > No idea. > > Not soon. > > Not writing the FAT by default gives half of the advantages and most > of the disadvantages of -async. > > Bruce > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed May 16 13:25:26 2001 Delivered-To: freebsd-fs@freebsd.org Received: from mail.webmonster.de (datasink.webmonster.de [194.162.162.209]) by hub.freebsd.org (Postfix) with ESMTP id C3E6437B423 for ; Wed, 16 May 2001 13:25:21 -0700 (PDT) (envelope-from karsten@rohrbach.de) Received: (qmail 57213 invoked by uid 1000); 16 May 2001 20:25:40 -0000 Date: Wed, 16 May 2001 22:25:40 +0200 From: "Karsten W. Rohrbach" To: Mikhail Teterin 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: <20010516222540.T46445@mail.webmonster.de> Mail-Followup-To: "Karsten W. Rohrbach" , Mikhail Teterin , bright@wintelcom.net, bsddiy@163.net, kris@obsecurity.org, grog@lemis.com, tlambert@primenet.com, mckusick@mckusick.com, ru@FreeBSD.org, fs@FreeBSD.org References: <20010514225533.M2009@fw.wintelcom.net> <200105151510.f4FFABt62656@aldan.algebra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200105151510.f4FFABt62656@aldan.algebra.com>; from mi@aldan.algebra.com on Tue, May 15, 2001 at 11:10:08AM -0400 X-Arbitrary-Number-Of-The-Day: 42 X-URL: http://www.webmonster.de/ X-Disclaimer: My opinions do not necessarily represent those of my employer Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Mikhail Teterin(mi@aldan.algebra.com)@2001.05.15 11:10:08 +0000: > [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. > > 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? several "production quality database"s use raw devices for holding the payload (speak: storage). so, what's this all about? using a filesystem to store multi-keyed data records is as inefficient as using a database to hold logfiles (hello sap ;-) just my EUR 0.02 /k -- > The idea that Bill Gates has appeared like a knight in shining armour > to lead all customers out of a mire of technological chaos neatly ignores > the fact that it was he who, by peddling second-rate technology, led them > into it in the first place. --Douglas Adams in Guardian, August 25, 1995 KR433/KR11-RIPE -- http://www.webmonster.de -- ftp://ftp.webmonster.de [Key] [KeyID---] [Created-] [Fingerprint-------------------------------------] GnuPG 0x2964BF46 2001-03-15 42F9 9FFF 50D4 2F38 DBEE DF22 3340 4F4E 2964 BF46 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed May 16 16:58:29 2001 Delivered-To: freebsd-fs@freebsd.org Received: from smtp10.phx.gblx.net (smtp10.phx.gblx.net [206.165.6.140]) by hub.freebsd.org (Postfix) with ESMTP id 19FE637B422 for ; Wed, 16 May 2001 16:58:27 -0700 (PDT) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp10.phx.gblx.net (8.9.3/8.9.3) id QAA52596; Wed, 16 May 2001 16:58:25 -0700 Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp10.phx.gblx.net, id smtpdHURsya; Wed May 16 16:58:20 2001 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id QAA27898; Wed, 16 May 2001 16:59:51 -0700 (MST) From: Terry Lambert Message-Id: <200105162359.QAA27898@usr01.primenet.com> Subject: Re: UFS to FAT32 To: bde@zeta.org.au (Bruce Evans) Date: Wed, 16 May 2001 23:59:41 +0000 (GMT) Cc: sparvu@cc.hut.fi (Stefan Parvu), freebsd-fs@FreeBSD.ORG, fbsdq@yahoo.com In-Reply-To: from "Bruce Evans" at May 16, 2001 07:57:05 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-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > I tested FreeBSD 4.3-RELEASE doing this : > > > > 1. mount /win98 partition as rw only. Move from BSD partition to FAT32 a > > file of 500MB. Time around 25min. System really slow. CPU as idle around > > 99% but vmstat reported a lot of blocked processes(2to6). Can't work > > anymore in the box until de copy operation finished. > > This is probably caused by new (in 4.3) default of write caching turned > off for ATA drives. I'm not sure why it blocks so many processes. > It should only make the system unusable when many processes other than > the copy hog want to access the disk :-]. It happens because it puts so many requests in line in front of all the other requests in your system. The line to get to the disk is FIFO, not fair-share. 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-fs" in the body of the message From owner-freebsd-fs Wed May 16 23:53:53 2001 Delivered-To: freebsd-fs@freebsd.org Received: from eniac.cable.net.co (eniac.cable.net.co [196.27.25.66]) by hub.freebsd.org (Postfix) with ESMTP id 26F8237B424 for ; Wed, 16 May 2001 23:53:25 -0700 (PDT) (envelope-from servicios@digitecnia.com) Received: from localhost ([209.88.49.106]) by eniac.cable.net.co (Post.Office MTA v3.5.3 release 223 ID# 637-71558U30000L25000S0V35) with ESMTP id co for ; Thu, 17 May 2001 01:58:27 -0500 X-Sender: servicios@digitecnia.com From: digitecnia.com To: freebsd-fs@freebsd.org Date: Thu, 17 May 2001 01:53:42 -0500 Subject: Su negocio esta al aire?... o en el aire? MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001__38118878_6822,95" Message-Id: <20010517065325.26F8237B424@hub.freebsd.org> Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a Multipart MIME message. ------=_NextPart_000_001__38118878_6822,95 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit ------=_NextPart_000_001__38118878_6822,95 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjx0aXRsZT5XRUJQQUNLIERJR0lURUNOSUE8L3RpdGxlPg0KPG1l dGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9aXNvLTg4NTktMSI+DQo8U1RZTEU+DQo8IS0tDQphOmxpbmsgeyB0ZXh0LWRlY29yYXRp b24gOiBub25lOyBjb2xvciA6IHdoaXRlOyB9DQphOnZpc2l0ZWQgeyB0ZXh0LWRlY29yYXRp b24gOiBub25lOyBjb2xvciA6IHdoaXRlOyB9DQphOmFjdGl2ZSB7IHRleHQtZGVjb3JhdGlv biA6IG5vbmU7IGNvbG9yIDogI0ZGMDAwMDsgfQ0KYTpob3ZlciB7IHRleHQtZGVjb3JhdGlv biA6IG5vbmU7IGNvbG9yIDogI0ZGMDAwMDsgfQ0KLS0+DQo8L1NUWUxFPg0KPC9oZWFkPg0K DQo8Ym9keSA8Ym9keSBzdHlsZT0iZm9udC1mYW1pbHk6IFZlcmRhbmE7IGZvbnQtc2l6ZTog MTAgcHQiIGJnY29sb3I9IiNmZmZmZmYiIHRleHQ9IiMwMDAwMDAiIGxpbms9IiMwMDAwOTki IHZsaW5rPSIjQ0NDQ0ZGIiBhbGluaz0iI0NDQ0NGRiINCiA+DQoNCjxwIGFsaWduPSJjZW50 ZXIiPg0KPGltZyBib3JkZXI9IjAiIHNyYz0iaHR0cDovL3d3dy5kaWdpdGVjbmlhLmNvbS9p bWFnZXMvMWEuZ2lmIiB3aWR0aD0iNDY4IiBoZWlnaHQ9IjYwIj48L3A+DQoNCjxwIGFsaWdu PSJjZW50ZXIiPjxpbWcgYm9yZGVyPSIwIiBzcmM9Imh0dHA6Ly93d3cuZGlnaXRlY25pYS5j b20vaW1hZ2VzL3dlYnBhY2tfMDEuZ2lmIiB3aWR0aD0iMTYwIiBoZWlnaHQ9IjQwIj48L3A+ DQo8cCBhbGlnbj0ibGVmdCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMwMDY2RkYiPkVsIDxp PldFQlBBQ0s8L2k+Jm5ic3A7IGVzIHVuYSANCnNvbHVjafNuIGludGVncmFsIGNvbXB1ZXN0 YSBwb3IgbG9zIHNlcnZpY2lvcyBi4XNpY29zIG5lY2VzYXJpb3MgcGFyYSB0ZW5lciB1biAN CnNpdGlvIGVuIEludGVybmV0IGRlIHVuYSBmb3JtYSBy4XBpZGEsIGVjb27zbWljYSB5IHBy b2Zlc2lvbmFsLCBlc3RhIGNvbXB1ZXN0byANCnBvcjo8L2ZvbnQ+PC9wPg0KPHAgYWxpZ249 ImxlZnQiPjxmb250IGNvbG9yPSIjMDA2NkZGIj48Yj5Ob21icmUgZGUgRG9taW5pbzwvYj48 L2ZvbnQ+IFJlZ2lzdHJvIA0KcG9yIDEgYfFvJm5ic3A7IC0tIDxmb250IGNvbG9yPSIjRkZG RkZGIj4gPGEgaHJlZj0iaHR0cDovL3d3dy5zdS1lbXByZXNhLmNvbSI+DQo8Zm9udCBjb2xv cj0iIzAwMDAwMCI+d3d3LnN1LWVtcHJlc2EuY29tPC9mb250PjwvYT48L2ZvbnQ+IC0tPC9w Pg0KPHAgYWxpZ249ImxlZnQiPjxmb250IGNvbG9yPSIjMDA2NkZGIj48Yj5EaXNl8W8gV2Vi PC9iPjwvZm9udD4gDQpQb3J0YWRhIGluaWNpYWwsIDUgcGFnaW5hcyBhZGljaW9uYWxlcywg bG9nb3RpcG8geSAyIEZvcm11bGFyaW9zPC9wPg0KPHAgYWxpZ249ImxlZnQiPjxmb250IGNv bG9yPSIjMDA2NkZGIj48Yj5Ib3N0aW5nIFdlYjwvYj48L2ZvbnQ+IDEgYfFvIGRlIHNlcnZp Y2lvIGluY2x1aWRvLCBjb24gMjAgTUIgZGUgZXNwYWNpbzwvcD4NCjxwIGFsaWduPSJsZWZ0 Ij48Zm9udCBjb2xvcj0iIzAwNjZGRiI+PGI+NSBCdXpvbmVzIGRlIENvcnJlbyBFbGVjdHLz bmljbzwvYj48L2ZvbnQ+PC9wPg0KPGZvbnQgY29sb3I9IiNGRkZGMDAiPg0KPHAgYWxpZ249 ImxlZnQiPjwvZm9udD48Yj48Zm9udCBjb2xvcj0iIzAwNjZGRiI+VmFsb3I8L2ZvbnQ+IDQ5 MCBE82xhcmVzPC9iPjwvcD4NCjxwIGFsaWduPSJsZWZ0Ij4mbmJzcDs8L3A+DQo8cCBhbGln bj0iY2VudGVyIj48Zm9udCBjb2xvcj0iI0ZGMDAwMCI+PGI+QWRpY2lvbmVzIGFsIFdFQlBB Q0s6PC9iPjwvZm9udD48L3A+DQo8cCBhbGlnbj0ibGVmdCI+PGZvbnQgY29sb3I9IiNGRjAw MDAiPjxiPk51ZXZvISANClBsdWcgQ29tZXJjaWFsIDwvYj48L2ZvbnQ+Q29uc2lzdGUgZW4g dW4gcGFxdWV0ZSANCmFkaWNpb25hbCwgcXVlIHBlcm1pdGUgbGEgaW1wbGVtZW50YWNp824g ZGUgY29tZXJjaW8gZWxlY3Ry825pY28gZW4gc3Ugc2l0aW8gDQpXZWIuIEVzdGEgY29tcHVl c3RvIHBvciBlbCBzaXN0ZW1hIGRlIGNhdGFsb2dvIGVuIGztbmVhLCBjYXJyaXRvIGRlIGNv bXByYXMsIA0KbW9kdWxvIGRlIGFkbWluaXN0cmFjafNuIHkgdW4gY3Vyc28gdmlydHVhbCBk ZSBjb21lcmNpbyBlbGVjdHLzbmljby4gMSBh8W8gZGUgDQpzZXJ2aWNpbyBpbmNsdWlkby4g PGZvbnQgY29sb3I9IiNGRjAwMDAiPlZhbG9yIDIxMCBE82xhcmVzPC9mb250PjwvcD4NCjxw IGFsaWduPSJsZWZ0Ij48Zm9udCBjb2xvcj0iI0ZGMDAwMCI+RGlzZfFvIGRlIFBhZ2luYSBh ZGljaW9uYWw6PC9mb250PiAzMCBE82xhcmVzIGMvdTwvcD4NCjxwIGFsaWduPSJsZWZ0Ij48 Zm9udCBjb2xvcj0iI0ZGMDAwMCI+Rm9ybXVsYXJpbyBjb24gZW52aW8gZGUgcmVzdWx0YWRv cyBhIHVuIA0KZW1haWw6PC9mb250PiAyNSBE82xhcmVzIGMvdTwvcD4NCjxwIGFsaWduPSJs ZWZ0Ij4mbmJzcDs8L3A+DQo8cCBhbGlnbj0ibGVmdCI+PGZvbnQgY29sb3I9IiMwMDY2RkYi PlNpIGVzdGEgaW50ZXJlc2FkbyBlbiBlbCBXRUJQQUNLLCBwb3IgDQpmYXZvciBsbGVuZSBl bCBzaWd1aWVudGUgZm9ybXVsYXJpbzo8L2ZvbnQ+PC9wPg0KDQogICAgICAgICAgPEZPUk0g YWN0aW9uPWh0dHA6Ly82My4xNjYuMTE3LjQxL3NlbmRtYWlsLmNmbSBtZXRob2Q9cG9zdD4N CiAgICAgICAgICAgIDxJTlBVVCANCiAgICAgIG5hbWU9ZW1haWx0byB0eXBlPWhpZGRlbiB2 YWx1ZT12ZW50YXNAZGlnaXRlY25pYS5jb20+DQogICAgICAgICAgICA8SU5QVVQgbmFtZT1l bWFpbGZyb20gDQogICAgICB0eXBlPWhpZGRlbiB2YWx1ZT13ZWJwYWNrPg0KICAgICAgICAg ICAgPElOUFVUIG5hbWU9ZW1haWxzdWJqZWN0IHR5cGU9aGlkZGVuIA0KICAgICAgdmFsdWU9 d2VicGFjaz4NCiAgICAgICAgICAgIDxJTlBVVCBuYW1lPWVtYWlsY29uZmlybSB0eXBlPWhp ZGRlbiANCiAgICAgIHZhbHVlPWh0dHA6Ly93d3cuZGlnaXRlY25pYS5jb20vY29uZmlybWFj aW9uLmh0bT4NCjx0YWJsZSBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2lu Zz0iMCIgc3R5bGU9ImJvcmRlci1jb2xsYXBzZTogY29sbGFwc2UiIGJvcmRlcmNvbG9yPSIj MTExMTExIiB3aWR0aD0iMTAwJSIgaWQ9IkF1dG9OdW1iZXIxIj4NCiAgICA8dHI+DQogICAg ICA8dGQgd2lkdGg9IjE2JSI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMwMDY2RkYiPk5vbWJy ZTwvZm9udD48L3RkPg0KICAgICAgPHRkIHdpZHRoPSI4NCUiPjxpbnB1dCB0eXBlPSJ0ZXh0 IiBuYW1lPSJub21icmUiIHNpemU9IjIwIj48L3RkPg0KICAgIDwvdHI+DQogICAgPHRyPg0K ICAgICAgPHRkIHdpZHRoPSIxNiUiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMDA2NkZGIj5F bXByZXNhPC9mb250PjwvdGQ+DQogICAgICA8dGQgd2lkdGg9Ijg0JSI+PGlucHV0IHR5cGU9 InRleHQiIG5hbWU9ImVtcHJlc2EiIHNpemU9IjIwIj48L3RkPg0KICAgIDwvdHI+DQogICAg PHRyPg0KICAgICAgPHRkIHdpZHRoPSIxNiUiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMDA2 NkZGIj5DaXVkYWQ8L2ZvbnQ+PC90ZD4NCiAgICAgIDx0ZCB3aWR0aD0iODQlIj48aW5wdXQg dHlwZT0idGV4dCIgbmFtZT0iY2l1ZGFkIiBzaXplPSIyMCI+PC90ZD4NCiAgICA8L3RyPg0K ICAgIDx0cj4NCiAgICAgIDx0ZCB3aWR0aD0iMTYlIj48Zm9udCBzaXplPSIyIiBjb2xvcj0i IzAwNjZGRiI+UGHtczwvZm9udD48L3RkPg0KICAgICAgPHRkIHdpZHRoPSI4NCUiPjxpbnB1 dCB0eXBlPSJ0ZXh0IiBuYW1lPSJwYWlzIiBzaXplPSIyMCI+PC90ZD4NCiAgICA8L3RyPg0K ICAgIDx0cj4NCiAgICAgIDx0ZCB3aWR0aD0iMTYlIj48Zm9udCBzaXplPSIyIiBjb2xvcj0i IzAwNjZGRiI+RGlyZWNjafNuPC9mb250PjwvdGQ+DQogICAgICA8dGQgd2lkdGg9Ijg0JSI+ PGlucHV0IHR5cGU9InRleHQiIG5hbWU9ImRpcmVjY2lvbiIgc2l6ZT0iMjAiPjwvdGQ+DQog ICAgPC90cj4NCiAgICA8dHI+DQogICAgICA8dGQgd2lkdGg9IjE2JSI+PGZvbnQgc2l6ZT0i MiIgY29sb3I9IiMwMDY2RkYiPlRlbOlmb25vPC9mb250PjwvdGQ+DQogICAgICA8dGQgd2lk dGg9Ijg0JSI+PGlucHV0IHR5cGU9InRleHQiIG5hbWU9InRlbGVmb25vIiBzaXplPSIyMCI+ PC90ZD4NCiAgICA8L3RyPg0KICAgIDx0cj4NCiAgICAgIDx0ZCB3aWR0aD0iMTYlIj48Zm9u dCBzaXplPSIyIiBjb2xvcj0iIzAwNjZGRiI+ZW1haWw8L2ZvbnQ+PC90ZD4NCiAgICAgIDx0 ZCB3aWR0aD0iODQlIj48aW5wdXQgdHlwZT0idGV4dCIgbmFtZT0iZW1haWwiIHNpemU9IjIw Ij48L3RkPg0KICAgIDwvdHI+DQogICAgPHRyPg0KICAgICAgPHRkIHdpZHRoPSIxNiUiPiZu YnNwOzwvdGQ+DQogICAgICA8dGQgd2lkdGg9Ijg0JSI+PGZvbnQgY29sb3I9IiMwMDY2RkYi Pg0KICAgICAgPGlucHV0IHR5cGU9ImNoZWNrYm94IiBuYW1lPSJ3ZWJwYWNrIiB2YWx1ZT0i T04iPjwvZm9udD48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzAwNjZGRiI+V0VCUEFDSzwvZm9u dD48L3RkPg0KICAgIDwvdHI+DQogICAgPHRyPg0KICAgICAgPHRkIHdpZHRoPSIxNiUiPiZu YnNwOzwvdGQ+DQogICAgICA8dGQgd2lkdGg9Ijg0JSI+PGZvbnQgY29sb3I9IiMwMDY2RkYi Pg0KICAgICAgPGlucHV0IHR5cGU9ImNoZWNrYm94IiBuYW1lPSJ3ZWJwYWNrcGx1Z2NvbWVy Y2lhbCIgdmFsdWU9Ik9OIj48L2ZvbnQ+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMwMDY2RkYi PldFQlBBQ0sgDQogICAgICArIFBsdWcgQ29tZXJjaWFsPC9mb250PjwvdGQ+DQogICAgPC90 cj4NCiAgICA8dHI+DQogICAgICA8dGQgd2lkdGg9IjE2JSI+DQogIDxpbnB1dCB0eXBlPSJz dWJtaXQiIHZhbHVlPSJPSyIgbmFtZT0iQjEiIHN0eWxlPSJmbG9hdDogcmlnaHQiPjxwPjwv cD4NCiAgPHA+PC90ZD4NCiAgICAgIDx0ZCB3aWR0aD0iODQlIj4NCiAgICAgIDxibG9ja3F1 b3RlPg0KJm5ic3A7PHA+PGZvbnQgc2l6ZT0iMiI+Tm90YTogRXMgcG9zaWJsZSBxdWUgZXN0 ZSBmb3JtdWxhcmlvIG5vIGZ1bmNpb25lIGNvcnJlY3RhbWVudGUgDQplbiBhbGd1bm9zIHBy b2dyYW1hcyBkZSBjb3JyZW8gDQogICAgICBlbGVjdHLzbmljby4gUHVlZGUgY29tcGxldGFy bG8gZW4gbO1uZWEgZW46IGh0dHA6Ly93d3cuZGlnaXRlY25pYS5jb20vd2VicGFjay5odG0g PC9mb250PjwvcD4NCiAgICAgIDwvYmxvY2txdW90ZT4NCiAgICAgIDwvdGQ+DQogICAgPC90 cj4NCiAgPC90YWJsZT4NCiAgPHAgYWxpZ249ImNlbnRlciI+DQogICAgICAgICAgICA8L3A+ DQo8L2Zvcm0+DQo8cCBhbGlnbj0ibGVmdCI+PGI+byBjb250YWN0YXJzZSBhIDogdmVudGFz QGRpZ2l0ZWNuaWEuY29tPC9iPjwvcD4NCg0KPHAgYWxpZ249ImxlZnQiPiZuYnNwOzwvcD4N Cg0KPHAgYWxpZ249ImNlbnRlciI+d3d3LmRpZ2l0ZWNuaWEuY29tPC9wPg0KPHAgYWxpZ249 ImNlbnRlciI+PGZvbnQgc2l6ZT0iMSI+U0kgTk8gREVTRUEgUkVDSUJJUiBPRkVSVEFTIERF IERJR0lURUNOSUEsIA0KQ09OVEVTVEUgRVNURSBFTUFJTCBDT04gTEEgUEFMQUJSQSBSRU1P VkVSIENPTU8gQVNVTlRPLjwvZm9udD48L3A+DQoNCjwvYm9keT4NCjwvaHRtbD4= ------=_NextPart_000_001__38118878_6822,95-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message