Date: Tue, 5 Jan 1999 04:28:14 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: dillon@apollo.backplane.com (Matthew Dillon) Cc: dg@root.com, hackers@FreeBSD.ORG Subject: Re: vfs_bio / struct buf Message-ID: <199901050428.VAA06606@usr05.primenet.com> In-Reply-To: <199812230444.UAA10868@apollo.backplane.com> from "Matthew Dillon" at Dec 22, 98 08:44:42 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> :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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901050428.VAA06606>