public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: hooanon05@yahoo.co.jp
To: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [RFC 7/8] Aufs2: mmap
Date: Mon, 23 Feb 2009 16:37:56 +0900	[thread overview]
Message-ID: <7828.1235374676@jrobl> (raw)
In-Reply-To: <7558.1235374266@jrobl>


> This is my second trial to ask incorporating aufs into mainline.


mmap(2) -- File Memory Mapping
----------------------------------------------------------------------
In aufs, the file-mapped pages are shared between the file on a branch
and the virtual one in aufs by overriding vm_operation, particularly
->fault().

In aufs_mmap(),
- get and store vm_ops of the real file on a branch.
- map the file of aufs by generic_file_mmap() and set aufs's vm
  operations.

In aufs_fault(),
- get the file of aufs from the passed vma, sleep if needed.
- get the real file on a branch from the aufs file.
- a race may happen. for instance a multithreaded library. so some lock
  is implemented.
- call ->fault() in the previously stored vm_ops with setting the
  real file on a branch to vm_file.
- restore vm_file and wake_up if someone else got sleep.

When a branch is added to or deleted from aufs, the same-named file may
unveil and its contents will be replaced by the new one when a process
read(2) through previously opened file.
(Some users may not want to refresh the filedata. For such users, I
have a plan to implement a mount option 'refrof' which decides to
refresh the opened files or not. See plan.txt too.)
In this case, an already mapped file will not be updated since the
contents are a part of a process already and it should not be changed by
aufs branch manipulation. Of course, in case of the deleting branch has a
busy file, it cannot be deleted from the union.

In Unionfs, it took an approach which the memory pages mapped to
filedata are copied from the lower (real) file into the Unionfs's
virtual one and handles it by address_space operations. Recently Unionfs
changed it to this approach which aufs adopted since Jul 2006.

  parent reply	other threads:[~2009-02-23  7:38 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-23  7:31 [RFC 0/8] Aufs2 documents hooanon05
2009-02-23  7:33 ` [RFC 1/8] Aufs2: introduction hooanon05
2009-02-23  7:34 ` [RFC 2/8] Aufs2: structure hooanon05
2009-02-23  9:13   ` Tomas M
2009-02-23  9:22     ` Tomas M
2009-02-24  8:13       ` New filesystem for Linux kernel Tomas M
2009-02-24 11:52         ` Miklos Szeredi
2009-02-24 13:18           ` hooanon05
2009-02-24 13:45             ` Tarkan Erimer
2009-02-24 13:57               ` hooanon05
2009-02-24 14:16                 ` Tarkan Erimer
2009-02-24 14:50             ` Miklos Szeredi
2009-02-24 16:26               ` hooanon05
2009-02-25 10:28                 ` Miklos Szeredi
2009-02-26  4:09                   ` hooanon05
2009-02-26  5:51               ` hooanon05
2009-02-26  5:55                 ` hooanon05
2009-02-24 14:15         ` Theodore Tso
2009-02-24 15:18           ` David P. Quigley
2009-02-24 15:41             ` hooanon05
2009-02-25 15:53               ` David P. Quigley
2009-02-26  4:21                 ` hooanon05
2009-02-25  7:31             ` Tomas M
2009-02-25  9:33               ` David Newall
2009-02-25  8:12           ` Tomas M
2009-02-26 14:31           ` Amit Kucheria
2009-02-23 14:23     ` [RFC 2/8] Aufs2: structure hooanon05
2009-02-23  7:35 ` [RFC 3/8] Aufs2: lookup hooanon05
2009-02-23  7:36 ` [RFC 4/8] Aufs2: branch hooanon05
2009-02-23  7:36 ` [RFC 5/8] Aufs2: wbr_policy hooanon05
2009-02-23  7:37 ` [RFC 6/8] Aufs2: fmode_exec hooanon05
2009-02-23  7:37 ` hooanon05 [this message]
2009-02-23  9:18   ` [RFC 7/8] Aufs2: mmap Tomas M
2009-02-23 14:39     ` hooanon05
2009-02-23  7:38 ` [RFC 8/8] Aufs2: plan hooanon05
2009-02-25 17:50 ` [RFC 0/8] Aufs2 documents David P. Quigley
2009-02-25 19:07   ` Matthew Wilcox
2009-02-26  4:54   ` hooanon05
2009-02-26 17:20     ` David P. Quigley
2009-02-27 14:27       ` hooanon05
2009-02-27 18:17         ` David P. Quigley
2009-02-28  8:04           ` hooanon05

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=7828.1235374676@jrobl \
    --to=hooanon05@yahoo.co.jp \
    --cc=linux-fsdevel@vger.kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox