All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: Anton Altaparmakov <aia21@cam.ac.uk>
Cc: linux-kernel@vger.kernel.org
Subject: Re: question about dirty buffers in page cache pages
Date: Tue, 29 Jun 2004 03:40:10 -0700	[thread overview]
Message-ID: <20040629034010.165b0481.akpm@osdl.org> (raw)
In-Reply-To: <1088504928.16560.25.camel@imp.csi.cam.ac.uk>

Anton Altaparmakov <aia21@cam.ac.uk> wrote:
>
> Hi Andrew and anyone else knowledgeable on LKML,
> 
> Given:
> - a file system (NTFS)
> - an inode on the file system
> - a mapping belonging to the inode
> - only address space operations in the mapping defined are readpage,
> sync_page, and writepage (my_writepage)
> - a page cache page in the mapping which is marked dirty
> - some buffers (perhaps all, but perhaps only some) in the page are
> marked dirty
> 
> Is it possible that write i/o is initiated on these buffers in any other
> way than through the above my_writepage?

No.  The VFS doesn't even know that the page has attached buffers.  It's
up the the a_ops to tell the VFS library functions that the thing at
page->private is a buffer_head ring.

do_writepages->generic_writepages->mpage_writepages->writepage.
pageout->writepage

> I guess the question can be also rephrased like so:  Is it possible for
> dirty buffers in an address space mapping to be written out by the
> kernel while bypassing the writepage address space operation?

In 2.4, yes.  Not in 2.6.

> Or in a different way:  Are dirty buffers in an address space entirely
> under the control of the address space operations defined by the owner
> of the address space?

yup.  There are a few VFS functions which fall through and play with the
buffer_heads if the filesystem failed to install an a_op, such as
set_page_dirty().  These exist because we never got around to editing all
the filesystems' a_ops.  But as long as the fs installs non-zero function
pointers in there, the fs is fully in control of whatever is at
page->private.

           reply	other threads:[~2004-06-29 10:41 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <1088504928.16560.25.camel@imp.csi.cam.ac.uk>]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040629034010.165b0481.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=aia21@cam.ac.uk \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.