From owner-freebsd-hackers  Mon Dec 11  8:58:39 2000
From owner-freebsd-hackers@FreeBSD.ORG  Mon Dec 11 08:58:36 2000
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
Delivered-To: freebsd-hackers@freebsd.org
Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135])
	by hub.freebsd.org (Postfix) with ESMTP id 2333C37B400
	for <freebsd-hackers@freebsd.org>; Mon, 11 Dec 2000 08:58:36 -0800 (PST)
Received: (from dillon@localhost)
	by earth.backplane.com (8.11.1/8.9.3) id eBBGwC091426;
	Mon, 11 Dec 2000 08:58:12 -0800 (PST)
	(envelope-from dillon)
Date: Mon, 11 Dec 2000 08:58:12 -0800 (PST)
From: Matt Dillon <dillon@earth.backplane.com>
Message-Id: <200012111658.eBBGwC091426@earth.backplane.com>
To: Alfred Perlstein <bright@wintelcom.net>
Cc: freebsd-hackers@freebsd.org
Subject: Re: cvs commit: src/sys/vm vm_pageout.c
References: <200012110756.eBB7uWp34663@freefall.freebsd.org> <20001211035441.Z16205@fw.wintelcom.net>
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

:I feel like a dolt here, but could you run these deltas by
:me or alc?
:
:Shouldn't it be using bogus_page here?
:
:-- 
:-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]

    Let me respond to -hackers here.  My commit comment isn't
    that good.

    Lets say you have a normal filesystem (1K frag, 8K block), and
    a small 2K file.  The struct buf associated with the file will
    only have a b_bufsize of 2K (rather then 8K) in this case.

    Now lets say you mmap() the file shared + R/W.  The mmap()ing will
    cause the VM page backing the buffer to be made all valid
    (m->valid = VM_PAGE_BITS_ALL).

    Now lets say you dirty the page via the mmap, by writing to memory.
    This will cause a VM fault which will make the underlying page 
    all dirty (m->dirty = VM_PAGE_BITS_ALL).

    This is all correct so far.  But now the filesystem comes along and
    flushes the underlying filesystem buffer.  This will sync the page to
    the filesystem, which is what we want.  But remember, the file is only
    2K!  So the end of the I/O operation only 'cleans' the first 2K of
    the page, leaving m->dirty = 0xFC.  The page is truely completely
    'clean', but it's still left marked dirty from the VM system's point
    of view.

    Now vm_object_page_clean() comes along and says 'look!  A page without
    a filesystem buffer that's dirty.  I need to flush it'.  Which it does.

    My KASSERT was asserting that the page had to be fully dirty, and under
    normal circumstances it has to be.  Until we fix how the filesystem deals
    with backing pages in the fragment case, I have to take that part of
    the KASSERT out.

						-Matt




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