From owner-cvs-all Wed Dec 8 8:57:22 1999 Delivered-To: cvs-all@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id E3F3014CEB; Wed, 8 Dec 1999 08:57:18 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id IAA37684; Wed, 8 Dec 1999 08:56:32 -0800 (PST) (envelope-from dillon) Date: Wed, 8 Dec 1999 08:56:32 -0800 (PST) From: Matthew Dillon Message-Id: <199912081656.IAA37684@apollo.backplane.com> To: Greg Lehey Cc: "Justin T. Gibbs" , Mike Smith , Julian Elischer , cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: Ordered writes and completion (was: cvs commit: src/sys/kern kern_shutdown.c) References: <19991207205800.62679@mojave.sitaranetworks.com> <199912081614.JAA00421@caspian.plutotech.com> <19991208113055.01750@mojave.sitaranetworks.com> Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk :>> would be noticable, but the difference definitely exists. :> :> If the application is bound by write latency, it is not written :> properly. Async I/O was developed for a reason. : :That's a definition. But it doesn't alter the fact that there are a :lot of improperly written applications out there. : :Greg Well, we are really talking about the kernel's ability to cache writes here. Under normal circumstances that ability is "good". When saturating the system with writes then there are definitely a number of tuning issues (Alfred just found one a day or two ago with clustering), and at least one operational issue (the contents of a buffer cannot be modified while the buffer is in-transit) but none of these issues are related to sequencing I/O. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message