Merge tag 'v3.3.7' into 3.3/master
[zen-stable.git] / Documentation / filesystems / aufs / design / 10dynop.txt
blobb5d536e590ea32b2ad27aa617becd9dad9e69661
2 # Copyright (C) 2010-2011 Junjiro R. Okajima
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.
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.
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
18 Dynamically customizable FS operations
19 ----------------------------------------------------------------------
20 Generally FS operations (struct inode_operations, struct
21 address_space_operations, struct file_operations, etc.) are defined as
22 "static const", but it never means that FS have only one set of
23 operation. Some FS have multiple sets of them. For instance, ext2 has
24 three sets, one for XIP, for NOBH, and for normal.
25 Since aufs overrides and redirects these operations, sometimes aufs has
26 to change its behaviour according to the branch FS type. More imporantly
27 VFS acts differently if a function (member in the struct) is set or
28 not. It means aufs should have several sets of operations and select one
29 among them according to the branch FS definition.
31 In order to solve this problem and not to affect the behavour of VFS,
32 aufs defines these operations dynamically. For instance, aufs defines
33 aio_read function for struct file_operations, but it may not be set to
34 the file_operations. When the branch FS doesn't have it, aufs doesn't
35 set it to its file_operations while the function definition itself is
36 still alive. So the behaviour of io_submit(2) will not change, and it
37 will return an error when aio_read is not defined.
39 The lifetime of these dynamically generated operation object is
40 maintained by aufs branch object. When the branch is removed from aufs,
41 the reference counter of the object is decremented. When it reaches
42 zero, the dynamically generated operation object will be freed.
44 This approach is designed to support AIO (io_submit), Direcit I/O and
45 XIP mainly.
46 Currently this approach is applied to file_operations and
47 vm_operations_struct for regular files only.