cvs commit: src/sys/fs/nullfs null.h null_subr.c null_vnops.c

David Schultz das at FreeBSD.ORG
Thu Jun 19 04:35:01 PDT 2003


On Wed, Jun 18, 2003, Poul-Henning Kamp wrote:
> In message <20030618112226.GA42606 at 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.


More information about the freebsd-arch mailing list