Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 08 Jul 1999 08:36:19 +0800
From:      Peter Wemm <peter@netplex.com.au>
To:        Jason Thorpe <thorpej@nas.nasa.gov>
Cc:        Matthew Dillon <dillon@apollo.backplane.com>, Julian Elischer <julian@whistle.com>, David Greenman <dg@root.com>, freebsd-hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG
Subject:   Re: Heh heh, humorous lockup 
Message-ID:  <19990708003619.7032B79@overcee.netplex.com.au>
In-Reply-To: Your message of "Wed, 07 Jul 1999 17:23:57 MST." <199907080023.RAA19330@lestat.nas.nasa.gov> 

next in thread | previous in thread | raw e-mail | index | archive | help
Jason Thorpe wrote:
> On Wed, 7 Jul 1999 17:03:16 -0700 (PDT) 
>  Matthew Dillon <dillon@apollo.backplane.com> wrote:
> 
>  >     If this could result in a smaller overall structure, it may be worth i
    t.
>  >     To really make the combined structure smaller we would also have to 
>  >     pair-down the fields in both structures.  For example, the vnode struc
    ture
>  >     contains a lot of temporary clustering fields that could be removed
>  >     entirely if clustering operations are done at the time of the actual I
    /O
>  >     rather then before hand ( which leads to other problems related to 
>  >     low-memory deadlocks :-(... but assuming that could be fixed... ).
> 
> The way this is done in the still-in-development branch of NetBSD's
> unified buffer cache is to basically elimiate the old buffer cache
> interface for vnode read/write completely.  When you want to do that
> sort of I/O to a vnode, you simply map a window of the object into
> KVA space (via ubc_alloc()), do the uiomove (lettings the pages fault
> in as necessary, getting added to the vnode's memq), and release the
> window (via ubc_release()).  The actual window mappings themselves can
> persist, as well (although those mappings are nuked immediately if the
> vnode is marked VTEXT on VAC machines, to eliminate bad cache interactions).

Out of curiosity, how does it handle the problem of small 512 byte
directories?  Does it consume a whole page or does it do something smarter?
Or does the ubc work apply to read/write only and the filesystem itself
continues to use the buffer cache interfaces for metadata and directories
still?  Does the caching part of the bio system still exist?

Cheers,
-Peter



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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990708003619.7032B79>