From owner-freebsd-fs Fri Jan 4 16:47:20 2002 Delivered-To: freebsd-fs@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 86C6037B41C for ; Fri, 4 Jan 2002 16:47:16 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g050lFg89490; Fri, 4 Jan 2002 16:47:15 -0800 (PST) (envelope-from dillon) Date: Fri, 4 Jan 2002 16:47:15 -0800 (PST) From: Matthew Dillon Message-Id: <200201050047.g050lFg89490@apollo.backplane.com> To: Alfred Perlstein Cc: fs@FreeBSD.ORG Subject: Re: open("", O_DIRECT) broken. References: <20020104172833.R82406@elvis.mu.org> Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org :Open passed the O_DIRECT flag seems broken, instead of doing the :right thing which would be just to penalize buffers not in the :cache, what it does (at least from casual observation in ufs_readwrite) :is mark _all_ buffers read via a O_DIRECT file as wanting to be :discarded, this is bogus as you may read via an O_DIRECT method the :entire file and invalidate the cache of another process accessing :the same file. : :It would be much better to pass O_DIRECT down to bread{n} which :would only mark it as B_DIRECT if it's not found in the cache. : :The idea is to not be distruptive to the cache, not to prematurely :toss away buffers that may be otherwise benifiting from heavy cache :utilization. : :-- :-Alfred Perlstein [alfred@freebsd.org] I agree with your reasoning, but I am not about to change the semantics of bread(). bread is used everywhere. In fact, it is used so often that I would be mightily nervous bloating it with another argument. The current implementation works reasonably well for the most common use of O_DIRECT I/O, where generally certain portions of a file will always be accessed O_DIRECT while other portions will always be accessed without O_DIRECT. For example, when accessing a large database you may wish to allow the OS to cache management structures like embedded hash tables, but do your own caching of the (possibly terrabytes) of data in order to make the most efficient use of the cpu by avoiding unexpected blockages. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message