From owner-freebsd-current Wed Jul 7 17:36:34 1999 Delivered-To: freebsd-current@freebsd.org Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id 9A59F14C4A; Wed, 7 Jul 1999 17:36:21 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 7032B79; Thu, 8 Jul 1999 08:36:19 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.0.2 2/24/98 To: Jason Thorpe Cc: Matthew Dillon , Julian Elischer , David Greenman , freebsd-hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Heh heh, humorous lockup In-reply-to: Your message of "Wed, 07 Jul 1999 17:23:57 MST." <199907080023.RAA19330@lestat.nas.nasa.gov> Date: Thu, 08 Jul 1999 08:36:19 +0800 From: Peter Wemm Message-Id: <19990708003619.7032B79@overcee.netplex.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jason Thorpe wrote: > On Wed, 7 Jul 1999 17:03:16 -0700 (PDT) > Matthew Dillon 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-current" in the body of the message