From owner-freebsd-hackers  Tue Dec 22 17:20:48 1998
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id RAA01236
          for freebsd-hackers-outgoing; Tue, 22 Dec 1998 17:20:48 -0800 (PST)
          (envelope-from owner-freebsd-hackers@FreeBSD.ORG)
Received: from root.com (root.com [198.145.90.17])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA01224
          for <hackers@FreeBSD.ORG>; Tue, 22 Dec 1998 17:20:42 -0800 (PST)
          (envelope-from root@root.com)
Received: from root.com (localhost [127.0.0.1])
	by root.com (8.8.8/8.8.5) with ESMTP id RAA20237;
	Tue, 22 Dec 1998 17:21:10 -0800 (PST)
Message-Id: <199812230121.RAA20237@root.com>
To: Matthew Dillon <dillon@apollo.backplane.com>
cc: hackers@FreeBSD.ORG
Subject: Re: vfs_bio / struct buf 
In-reply-to: Your message of "Tue, 22 Dec 1998 16:16:49 PST."
             <199812230016.QAA08122@apollo.backplane.com> 
From: David Greenman <dg@root.com>
Reply-To: dg@root.com
Date: Tue, 22 Dec 1998 17:21:10 -0800
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

>:>    It is also glaringly obvious that there are some hacks in there that
>:>    we should probably work to remove.  We ought to be able to fix NFS
>:>    to not have to use the validoff/validend/dirtyoff/dirtyend junk, and 
>:>    we ought to be able to clean the system up such that it is possible
>:>    to get rid of the bogus_page stuff and we should also be able to fix
>:>    the bogus way pages are marked clean in the VFS layer ( rather then being
>:>    marked clean in the device layer ).  I may take this up post-3.0.1.
>:
>:   valid/dirty off/end are there to reduce wire traffic, but aren't strictly
>:necessary. We would not want to remove it.
>:
>:-DG
>
>    Right.  I don't see how they reduce the wire traffic, though, since
>    the page dirty and valid bits are already available with a DEV_BSIZE
>    (i.e. 512 byte) granularity.  Can't we just use the valid/dirty bits
>    to optimize NFS operations?

   The optimization is primarily for short writes (like 1 byte or a few bytes)
so couldn't really be replaced by something that has 512 byte granularity
without losing some performance. Granted, applications that show this behavior
are probably broken, but that's another issue.

-DG

David Greenman
Co-founder/Principal Architect, The FreeBSD Project

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