From owner-freebsd-arch@FreeBSD.ORG Thu Jun 19 04:35:00 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C9AB037B401; Thu, 19 Jun 2003 04:35:00 -0700 (PDT) Received: from HAL9000.homeunix.com (ip114.bella-vista.sfo.interquest.net [66.199.86.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id E12EC43F3F; Thu, 19 Jun 2003 04:34:59 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.9/8.12.9) with ESMTP id h5JBYwJa081635; Thu, 19 Jun 2003 04:34:58 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.9/8.12.9/Submit) id h5JBYwZc081634; Thu, 19 Jun 2003 04:34:58 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Date: Thu, 19 Jun 2003 04:34:58 -0700 From: David Schultz To: Poul-Henning Kamp Message-ID: <20030619113457.GA80739@HAL9000.homeunix.com> Mail-Followup-To: Poul-Henning Kamp , Dmitry Sivachenko , "Tim J. Robbins" , arch@freebsd.org References: <20030618112226.GA42606@fling-wing.demos.su> <39081.1055937209@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <39081.1055937209@critter.freebsd.dk> cc: Dmitry Sivachenko cc: "Tim J. Robbins" cc: arch@FreeBSD.ORG Subject: Re: cvs commit: src/sys/fs/nullfs null.h null_subr.c null_vnops.c X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2003 11:35:01 -0000 On Wed, Jun 18, 2003, Poul-Henning Kamp wrote: > In message <20030618112226.GA42606@fling-wing.demos.su>, Dmitry Sivachenko writes > I am hoping that we may be able to carve a path by changing the > bio structure operate on vm pages rather than KVM mapped > byte arrays (most disk device drivers don't care for thing being > mapped, they use bus-master DMA and only need physical location). It would seem to me that we would ultimately want filesystems to be doing page-based I/O, rather than crafting ellaborate illusions to deal with FS blocks being smaller or larger than the VM page size. As a side note, I also think it's important that the new implementation have a clean separation between user data and FS metadata, so that they are not in direct competition with each other for memory. The present buffer cache may be too limited for the massive number of dependencies softupdates needs to track for FS-intensive loads, but we also don't want lots of accumulated dirty buffers from heavy FS activity to force application data out of memory. > With that said, I will also add, that I will take an incredibly > dim view of anybody who tries to add more gunk in this area, and > that I am perfectly willing to derail unionfs and nullfs (or pretty > much anything else on the list above) if that is what it takes to > clean up the buffer cache. Any of those facilities can be reintroduced > later on in a cleaner fashion. > > I agree that nullfs and unionfs are useful technologies, but if > they have to be reimplemented to fit our kernel, then so be it. The original buffer cache design is untenable largely because Dyson wanted to maintain compatibility with existing FS interfaces. Therefore, I would expect that moving forward and doing things right would require changes to existing filesystems. However, if your changes make nullfs and unionfs substantially *more* difficult to implement, then you've done something wrong. If I'm kept informed, I'm willing to contribute to this aspect of the task to the extent that I have time.