From owner-freebsd-hackers Thu Jan 7 17:06:47 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA06466 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 17:06:47 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA06460 for ; Thu, 7 Jan 1999 17:06:45 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id RAA36238; Thu, 7 Jan 1999 17:06:15 -0800 (PST) (envelope-from dillon) Date: Thu, 7 Jan 1999 17:06:15 -0800 (PST) From: Matthew Dillon Message-Id: <199901080106.RAA36238@apollo.backplane.com> To: Terry Lambert Cc: tlambert@primenet.com, dyson@iquest.net, pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG Subject: Re: questions/problems with vm_fault() in Stable Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :This is *not* a major improvement. It's a trivial improvement :which does nothing to address the issue of fragmentation. The :FFS/UFS combination on a fixed backing store is relative immune :to fragmentation because of the way the backing store is used via :what is, in effect, a statistical hash of blocks into the available :space for blocks. I'm sorry, I spent two days testing this. It is a *MAJOR* improvement. Fragmentation is not an issue. While it is true that swap backing for non-data blocks (i.e. fragments, inodes, bitmaps) cannot be recovered, the fact that data blocks *CAN* is *MAJOR* improvement. Fragmentation at the datablock level is irrelevant because it only applies to cleaning dirty pages -- i.e. paging out to SWAP, and the swap code will allocate *contiguous* space for the *fragmented* data. And with the new swapper going in on the 15th, it will even reallocate swap on the fly. The on-the-fly reallocation fixes *ALL* long term fragmentation issues with paging to swap whether it is for MFS or just standard OBJT_DEFAULT or OBJT_SWAP objects. So while the data blocks may be fragmented from the point of view of the MFS 'block' device, they are not fragmented from the point of view of the swap backing store block device. :The recovery mechanism you outline deals with breaking pages back :to the system for reuse, but *aggrivates* the fragmentation issue :to an almost unholy level, which just gets worse if you try and add :cylinder groups to "grow" the MFS. No it doesn't. Explain to me how it aggravates the fragmentation issue. Remember, we *don't* *care* how 'fragmented' the file data is in MFS's device namespace. We just care how fragmented it is on physical media - the swap backing store. The swapper automatically defragments anything over a page in size. -Matt : Terry Lambert : terry@lambert.org :--- Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications & God knows what else. (Please include original email in any response) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message