All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: question about dirty buffers in page cache pages
       [not found] <1088504928.16560.25.camel@imp.csi.cam.ac.uk>
@ 2004-06-29 10:40 ` Andrew Morton
  0 siblings, 0 replies; only message in thread
From: Andrew Morton @ 2004-06-29 10:40 UTC (permalink / raw)
  To: Anton Altaparmakov; +Cc: linux-kernel

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.

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2004-06-29 10:41 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <1088504928.16560.25.camel@imp.csi.cam.ac.uk>
2004-06-29 10:40 ` question about dirty buffers in page cache pages Andrew Morton

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.