From owner-freebsd-current  Wed Mar 22 16:10:44 2000
Delivered-To: freebsd-current@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by hub.freebsd.org (Postfix) with ESMTP
	id 1803B37C259; Wed, 22 Mar 2000 16:10:40 -0800 (PST)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id QAA94351;
	Wed, 22 Mar 2000 16:10:39 -0800 (PST)
	(envelope-from dillon)
Date: Wed, 22 Mar 2000 16:10:39 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200003230010.QAA94351@apollo.backplane.com>
To: Mike Smith <msmith@FreeBSD.ORG>
Cc: Paul Richards <paul@originative.co.uk>,
	Richard Wendland <richard@netcraft.com>,
	Alfred Perlstein <bright@wintelcom.net>,
	Poul-Henning Kamp <phk@critter.freebsd.dk>, current@FreeBSD.ORG,
	fs@FreeBSD.ORG
Subject: Re: FreeBSD random I/O performance issues 
References:  <200003222039.MAA00661@mass.cdrom.com>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


:
:>     effects of the I/O being in-progress.  If a user program doesn't access
:>     any of the information it recently wrote the whole mechanism winds up
:>     operating asynchronously in the background.  If a user program does, 
:>     then the write behind mechanism breaks down and you get a stall.
:
:What makes no sense is that it should be perfectly ok to _read_ this 
:information back.

    When we separate out the read vs write access in the buffer
    cache API we *will* be able to read the information back while a
    write is in progress.  At the moment the buffer cache has no clue
    how a buffer is going to be used, which means the buffer is locked
    exclusively.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message