From owner-freebsd-hackers Mon Jan 4 20:28:49 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA25099 for freebsd-hackers-outgoing; Mon, 4 Jan 1999 20:28:49 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA25093 for ; Mon, 4 Jan 1999 20:28:48 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id VAA24527; Mon, 4 Jan 1999 21:28:18 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp03.primenet.com, id smtpd024478; Mon Jan 4 21:28:16 1999 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id VAA06606; Mon, 4 Jan 1999 21:28:14 -0700 (MST) From: Terry Lambert Message-Id: <199901050428.VAA06606@usr05.primenet.com> Subject: Re: vfs_bio / struct buf To: dillon@apollo.backplane.com (Matthew Dillon) Date: Tue, 5 Jan 1999 04:28:14 +0000 (GMT) Cc: dg@root.com, hackers@FreeBSD.ORG In-Reply-To: <199812230444.UAA10868@apollo.backplane.com> from "Matthew Dillon" at Dec 22, 98 08:44:42 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > :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. > > Ah. Hmmm. I see the problem... the buf's need some sort of native block > size and NFS doesn't really have a native block size. Not to contrdict David, but I was under the impression that the reason for this code was not necessarily the read-before-write avoidance on small, unaligned regions, but was actually for the avoidance on aligned block sized or multiple of block size regions being written. The theory being that if you wrote a fragment of a NFS buffer size and did this sseveral times that you could just write it and not read at all. Mostly or database stuff, if I recall correctly. There's actually a byte field that's unused as far as I can tell to allow page granularity down to PAGE_SIZE/8 to be bitmapped for validity within a given page, for similar reasons. I went looking at this code when I had an MSDOS FS that used 1K blocks, but was not aligned on an even 1K boundary from the start of the device (odd cylinder size on the physical disk), which mean that every 4th 1K block spanned a page boundary (with obvious performance degradation during random access). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message