From owner-freebsd-current Sat Feb 10 11:55:00 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA07519 for current-outgoing; Sat, 10 Feb 1996 11:55:00 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA07509 for ; Sat, 10 Feb 1996 11:54:57 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA16344; Sat, 10 Feb 1996 12:49:34 -0700 From: Terry Lambert Message-Id: <199602101949.MAA16344@phaeton.artisoft.com> Subject: Re: How To: wscott@ichips.intel.com (Wayne Scott) Date: Sat, 10 Feb 1996 12:49:34 -0700 (MST) Cc: terry@lambert.org, coredump@onyx.nervosa.com, current@FreeBSD.ORG In-Reply-To: <199602101921.LAA12306@ichips.intel.com> from "Wayne Scott" at Feb 10, 96 11:21:15 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG Precedence: bulk > > > Just how dangerous is it to mount disks with async? If your machine > > > somehow crashes, do you rick losing all your data? Of course, you risk > > > that with sync also... > > > > IMO, very dangerous. > > Terry, > > Thanks for a good explaination of sync vs. async. > > I believe the Linux ext2 file system is always async. Is that > filesystem just as unstable or do they do something else to make it > easier to recover in the case of a crash. > > I have crashed Linux systems many many times and have not noticed a > real problem recovering. Am I just lucky? The combine metadata writes. This makes it less likely that the damage would be spread out (BSD async does the same thing). They sync frequently. This reduces the effectiveness of the cache and of the async settings. I think you have just been lucky. The typical "benchmark" they "win" on is the massive create followed by the massive delete in the lmbench suite, and Larry McVoy is known to have a strong personal bias toward Linux. I can not think of a situation that is not an abuse of the file system as a database (like terminfo files, only worse), or is not an administrative function (where an async mount could be done relatively safely) that would need the ability to create and then delete a lot of files fast. The benchmark *claims* compilers -- but since temp file systems can be non-persistant across reboots, both async and ramdisk approaches are viable, and the ramdisk approach is significantly faster. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.