Documentation/filesystems/aufs/design/99plan.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 Plan
  19
  20 Restoring some features which was implemented in aufs1.
  21 They were dropped in aufs2 in order to make source files simpler and
  22 easier to be reviewed.
  23
  24
  25 Test Only the Highest One for the Directory Permission (dirperm1 option)
  26 ----------------------------------------------------------------------
  27 Let's try case study.
  28 - aufs has two branches, upper readwrite and lower readonly.
  29   /au = /rw + /ro
  30 - "dirA" exists under /ro, but /rw. and its mode is 0700.
  31 - user invoked "chmod a+rx /au/dirA"
  32 - then "dirA" becomes world readable?
  33
  34 In this case, /ro/dirA is still 0700 since it exists in readonly branch,
  35 or it may be a natively readonly filesystem. If aufs respects the lower
  36 branch, it should not respond readdir request from other users. But user
  37 allowed it by chmod. Should really aufs rejects showing the entries
  38 under /ro/dirA?
  39
  40 To be honest, I don't have a best solution for this case. So I
  41 implemented 'dirperm1' and 'nodirperm1' option in aufs1, and leave it to
  42 users.
  43 When dirperm1 is specified, aufs checks only the highest one for the
  44 directory permission, and shows the entries. Otherwise, as usual, checks
  45 every dir existing on all branches and rejects the request.
  46
  47 As a side effect, dirperm1 option improves the performance of aufs
  48 because the number of permission check is reduced.
  49
  50
  51 Being Another Aufs's Readonly Branch (robr)
  52 ----------------------------------------------------------------------
  53 Aufs1 allows aufs to be another aufs's readonly branch.
  54 This feature was developed by a user's request. But it may not be used
  55 currecnly.
  56
  57
  58 Copy-up on Open (coo=)
  59 ----------------------------------------------------------------------
  60 By default the internal copy-up is executed when it is really necessary.
  61 It is not done when a file is opened for writing, but when write(2) is
  62 done. Users who have many (over 100) branches want to know and analyse
  63 when and what file is copied-up. To insert a new upper branch which
  64 contains such files only may improve the performance of aufs.
  65
  66 Aufs1 implemented "coo=none | leaf | all" option.
  67
  68
  69 Refresh the Opened File (refrof)
  70 ----------------------------------------------------------------------
  71 This option is implemented in aufs1 but incomplete.
  72
  73 When user reads from a file, he expects to get its latest filedata
  74 generally. If the file is removed and a new same named file is created,
  75 the content he gets is unchanged, ie. the unlinked filedata.
  76
  77 Let's try case study again.
  78 - aufs has two branches.
  79   /au = /rw + /ro
  80 - "fileA" exists under /ro, but /rw.
  81 - user opened "/au/fileA".
  82 - he or someone else inserts a branch (/new) between /rw and /ro.
  83   /au = /rw + /new + /ro
  84 - the new branch has "fileA".
  85 - user reads from the opened "fileA"
  86 - which filedata should aufs return, from /ro or /new?
  87
  88 Some people says it has to be "from /ro" and it is a semantics of Unix.
  89 The others say it should be "from /new" because the file is not removed
  90 and it is equivalent to the case of someone else modifies the file.
  91
  92 Here again I don't have a best and final answer. I got an idea to
  93 implement 'refrof' and 'norefrof' option. When 'refrof' (REFResh the
  94 Opened File) is specified (by default), aufs returns the filedata from
  95 /new.
  96 Otherwise from /new.