From owner-freebsd-hackers Sun Apr 2 10:32:07 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA05507 for hackers-outgoing; Sun, 2 Apr 1995 10:32:07 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.1]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id KAA05501 for ; Sun, 2 Apr 1995 10:32:00 -0700 Received: from jsdinc.root.com (uucp@localhost) by Root.COM (8.6.8/8.6.5) with UUCP id KAA01975; Sun, 2 Apr 1995 10:30:17 -0700 Received: (root@localhost) by jsdinc.root.com (8.6.11/8.6.5) id MAA00147; Sun, 2 Apr 1995 12:33:03 GMT From: "John S. Dyson" Message-Id: <199504021233.MAA00147@jsdinc.root.com> Subject: Re: 4 gig st15150n disk setups To: zeta.org.au!bde@implode.root.com (Bruce Evans) Date: Sun, 2 Apr 1995 12:33:03 +0000 () Cc: zeta.org.au!davidg@implode.root.com, terry@cs.weber.edu, bde@zeta.org.au, bugs@ns1.win.net, gary@palmer.demon.co.uk, hackers@FreeBSD.org, jkh@freefall.cdrom.com, tom@haven.uniserve.com In-Reply-To: <199504012235.IAA21888@godzilla.zeta.org.au> from "Bruce Evans" at Apr 2, 95 08:35:46 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2164 Sender: hackers-owner@FreeBSD.org Precedence: bulk > > The clustering code converts block numbers to byte offsets for some reason, > perhaps just because it wants to compare the byte offset with the file > size and multiplying by the block size is sometimes much more efficient > than dividing the file size by the block size and worrying about rounding. > The problem is that all VREG file buffering occurs through VM objects, which along with VM pages have 32Bit offsets with BYTE resolution. DG and I are looking into making the offsets into page offsets. Note that this is only true for VM clustering. VFS layer clustering has no such limitation. The limitation will be removed in V2.2. Note that we don't use the merged VM/Buffer cache for VBLK for this reason. It would be very unfortunate to limit the size of a device because of the size of a vm_offset_t wouldn't it??? I have looked into making vm_page_t offset into an off_t and it appears to be ugly because of the additional amount of space that it will need. Since pages are on page boundaries, it appears that making the offset into integral page offsets would not be a problem. However, this brings up an interesting problem on shadow_offsets and paging_offsets. They will have to be off_t's. In 2.2 I plan to add the capability of allowing "bogus" binary formats that are not page aligned. This will allow successful demand paging of ibcs2(or is it Linux?) binaries. Currently we need to read them in. In essence we will shadow the ibcs2 object with the actual vnode backed object, with a non-integral paging offset. Minor mods will need to be made to the fault code to effect this improvement. This means that the binarys with the bogus offsets will not be coherent with the buffer cache, but that is not that important as long as proper invalidation takes place. > seem to be many secondary problems. I gave up on the problem for a > while because it seemed that there were more fundamental problems in > the vm system. > Not really fundamental problems, but bugs. :-). Many fundamental improvments have been made, and the end result will be substantially better than the previous (4.4Lite-Net/2) stuff. John dyson@root.com