linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nikita Danilov <nikita@clusterfs.com>
To: Martin Jambor <jamborm@gmail.com>
Cc: linux-fsdevel@vger.kernel.org
Subject: Re: Address space operations questions
Date: Wed, 30 Mar 2005 17:55:16 +0400	[thread overview]
Message-ID: <16970.44996.53630.886769@gargle.gargle.HOWL> (raw)
In-Reply-To: <8e70aacf05032914306a827923@mail.gmail.com>

Martin Jambor writes:
 > Hi,
 > 
 > I have problems understanding the purpose of different entries of
 > struc address_space_operations in 2.6 kernels:
 > 
 > 1. What is bmap for and what is it supposed to do?

->bmap() maps logical block offset within "object" to physical block
number. It is used in few places, notably in the implementation of
FIBMAP ioctl.

 > 
 > 2. What is the difference between sync_page and write_page?

(It is spelt ->writepage() by the way).

->sync_page() is an awful misnomer. Usually, when page IO operation is
requested by calling ->writepage() or ->readpage(), file-system queues
IO request (e.g., disk-based file system may do this my calling
submit_bio()), but underlying device driver does not proceed with this
IO immediately, because IO scheduling is more efficient when there are
multiple requests in the queue.

Only when something really wants to wait for IO completion
(wait_on_page_{locked,writeback}() are used to wait for read and write
completion respectively) IO queue is processed. To do this
wait_on_page_bit() calls ->sync_page() (see block_sync_page()---standard
implementation of ->sync_page() for disk-based file systems).

So, semantics of ->sync_page() are roughly "kick underlying storage
driver to actually perform all IO queued for this page, and, maybe, for
other pages on this device too".

 > 
 > 3. What exactly (fs independent) is the relation in between
 > write_page, prepare_write and commit_write? Does prepare make sure a
 > page can be written (like allocating space), commit mark it dirty a
 > write write it sometime later on?

->prepare_write() and ->commit_write() are only used by
generic_file_write() (so, one may argue that they shouldn't be placed
into struct address_space at all).

generic_file_write() has a loop for each page overlapping with portion
of file that write goes into:

     a_ops->prepare_write(file, page, from, to);
     copy_from_user(...);
     a_ops->commit_write(file, page, from, to);

In page is partially overwritten, ->prepare_write() has to read parts of
the page that are not covered by write. ->commit_write() is expected to
mark page (or buffers) and inode dirty, and update inode size, if write
extends file.

As for block allocation and transaction handling, this is up to the file
system back end.

Usually ->commit_write() doesn't start IO by itself, it just marks pages
dirty. Write-out is done by balance_dirty_pages_ratelimited(): when
number of dirty pages in the system exceeds some threshold, kernel calls
->writepages() of dirty inodes.

->writepage() is used in two places:

    - by VM scanner to write out dirty page from tail of the inactive
    list.  This is "rare" path, because balance_dirty_pages() is
    supposed to keep amount of dirty pages under control.

    - by mpage_writepages(): default implementation of ->writepages()
    method.

 > 
 > Thak you very much for any insight,
 > 
 > Martin

Hope this helps.

Nikita.

  reply	other threads:[~2005-03-30 13:55 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <8e70aacf05032616151c958eed@mail.gmail.com>
2005-03-29 22:30 ` Address space operations questions Martin Jambor
2005-03-30 13:55   ` Nikita Danilov [this message]
2005-03-31 19:59     ` Bryan Henderson
2005-03-31 20:43       ` Zach Brown
2005-03-31 21:40         ` Bryan Henderson
2005-03-31 21:53           ` Trond Myklebust
2005-04-01  0:06             ` Bryan Henderson
2005-04-06 23:52     ` Martin Jambor
2005-04-07  8:23       ` Nikita Danilov
2005-04-17 20:21         ` Lilo requirements (Was: Re: Address space operations questions) Martin Jambor
2005-04-17 21:33           ` Nikita Danilov
2005-04-18 17:33             ` Bryan Henderson
2005-04-07 16:58       ` Address space operations - >bmap Bryan Henderson

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=16970.44996.53630.886769@gargle.gargle.HOWL \
    --to=nikita@clusterfs.com \
    --cc=jamborm@gmail.com \
    --cc=linux-fsdevel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).