Message 9

What is the intended behavior of flushPage() and flushAllPages()

X-Added: With Flames (bblib $Revision: 1.4 $)
Return-path: <twenisch@andrew.cmu.edu>
X-Andrew-Authenticated-as: 0;andrew.cmu.edu;Network-Mail
Received: from po0.andrew.cmu.edu via trymail for bb+academic.cs.15-721@andrew.cmu.edu
          ID </afs/andrew.cmu.edu/usr0/bb/Mailbox/Ivdsvda00UdYJQ0U4Y>;
          Tue, 18 Sep 2001 14:14:01 -0400 (EDT)
Received: from smtp6.andrew.cmu.edu (SMTP6.ANDREW.CMU.EDU [128.2.10.86])
        by po0.andrew.cmu.edu (8.9.3/8.9.3) with ESMTP id OAA23550
        for <bb+academic.cs.15-721@ams.andrew.cmu.edu>; Tue, 18 Sep 2001 14:14:00 -0400 (EDT)
Received: from UNIX3.ANDREW.CMU.EDU (UNIX3.ANDREW.CMU.EDU [128.2.11.203])
        (user=twenisch mech=KERBEROS_V4 (0 bits))
        by smtp6.andrew.cmu.edu (8.12.0.Beta16/8.12.0.Beta16) with ESMTP id f8IIE06E024675
        for <post+academic.cs.15-721@andrew.cmu.edu>; Tue, 18 Sep 2001 14:14:01 -0400
Date: Tue, 18 Sep 2001 14:14:00 -0400 (EDT)
From: Thomas Wenisch <twenisch@andrew.cmu.edu>
To: "cyrus.academic.cs.15-721" <post+academic.cs.15-721@andrew.cmu.edu>
Subject: What is the intended behavior of flushPage() and flushAllPages()
Message-ID: <Pine.GSO.4.33L-022.0109181256520.16305-100000@unix3.andrew.cmu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hey all,

        From the test code, I am unclear on what the behavior of
flushPage() and flushAllPages() should be.  My current implementation is
to write all dirty pages to disk, but otherwise leave all buffers
unchanged, so if someone tries to pin one of the pages, the page is still
present in the buffer, and does not need to be loaded.

        This behavior fails test 4.  Since the pages are still in frames,
I return true when checkPage() is called.  Test 4 uses checkPage() to
verify that the flush happened, on lines 495-504.  With my implementation,
this test will fail, even though I did flush.

        Test 4 seems to want "flush" to mean "empty the buffers".  In
other words, flushing means marking the page as not present, reset the LRU
stack (since all pages are now available, LRU is meaningless), and all
subsequent pins force pages to be loaded from disk.  This further implies
that flushing a pinned page is illegal, since a pinned page can't be
"ejected" from its buffer.  (My current implementation allows flushing a
pinned page.  It gets written to disk and the dirty bit is cleared, which
may then get set again when the page is unpinned).  If flushing a pinned
page is illegal, what should the behavior of flushAll() be?  Should it
skip pinned pages and flush unpinned ones, or should the call fail?

-Tom Wenisch
twenisch@andew.cmu.edu