Date: Thu, 19 Jun 2003 04:34:58 -0700 From: David Schultz <das@FreeBSD.ORG> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: arch@FreeBSD.ORG Subject: Re: cvs commit: src/sys/fs/nullfs null.h null_subr.c null_vnops.c Message-ID: <20030619113457.GA80739@HAL9000.homeunix.com> In-Reply-To: <39081.1055937209@critter.freebsd.dk> References: <20030618112226.GA42606@fling-wing.demos.su> <39081.1055937209@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030619113457.GA80739>