Documentation/filesystems/aufs/design/06mmap.txt

   1
   2 # Copyright (C) 2005-2011 Junjiro R. Okajima
   3 #
   4 # This program is free software; you can redistribute it and/or modify
   5 # it under the terms of the GNU General Public License as published by
   6 # the Free Software Foundation; either version 2 of the License, or
   7 # (at your option) any later version.
   8 #
   9 # This program is distributed in the hope that it will be useful,
  10 # but WITHOUT ANY WARRANTY; without even the implied warranty of
  11 # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  12 # GNU General Public License for more details.
  13 #
  14 # You should have received a copy of the GNU General Public License
  15 # along with this program; if not, write to the Free Software
  16 # Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
  17
  18 mmap(2) -- File Memory Mapping
  19 ----------------------------------------------------------------------
  20 In aufs, the file-mapped pages are handled by a branch fs directly, no
  21 interaction with aufs. It means aufs_mmap() calls the branch fs's
  22 ->mmap().
  23 This approach is simple and good, but there is one problem.
  24 Under /proc, several entries show the mmap-ped files by its path (with
  25 device and inode number), and the printed path will be the path on the
  26 branch fs's instead of virtual aufs's.
  27 This is not a problem in most cases, but some utilities lsof(1) (and its
  28 user) may expect the path on aufs.
  29
  30 To address this issue, aufs adds a new member called vm_prfile in struct
  31 vm_area_struct (and struct vm_region). The original vm_file points to
  32 the file on the branch fs in order to handle everything correctly as
  33 usual. The new vm_prfile points to a virtual file in aufs, and the
  34 show-functions in procfs refers to vm_prfile if it is set.
  35 Also we need to maintain several other places where touching vm_file
  36 such like
  37 - fork()/clone() copies vma and the reference count of vm_file is
  38   incremented.
  39 - merging vma maintains the ref count too.
  40
  41 This is not a good approach. It just faking the printed path. But it
  42 leaves all behaviour around f_mapping unchanged. This is surely an
  43 advantage.
  44 Actually aufs had adopted another complicated approach which calls
  45 generic_file_mmap() and handles struct vm_operations_struct. In this
  46 approach, aufs met a hard problem and I could not solve it without
  47 switching the approach.