~azzar1/unity/add-show-desktop-key

« back to all changes in this revision

Viewing changes to doc/dev/architecture.rst

  • Committer: Matt Giuca
  • Date: 2009-12-01 07:26:06 UTC
  • Revision ID: matt.giuca@gmail.com-20091201072606-y1yfjhcjozjzjw5b
doc/dev/architecture: Moved the discussion of the historical solutions to the mounting problem into a separate note, so the main text just explains the current system.

Show diffs side-by-side

added added

removed removed

Lines of Context:
126
126
-------------------------
127
127
 
128
128
To give the appearance of a private file system we need to merge together a 
129
 
user's local home directory with the base image. In the first release of IVLE 
130
 
this was done off-line by hardlinking all the files into the target directory, 
131
 
but for more than a handful of users this process could take several hours and 
132
 
also ran the risk of exhausting inodes on the underlying file system.
133
 
 
134
 
The first solution was to use  `AUFS <http://aufs.sourceforge.net/>`_ to mount 
135
 
the user's home directory over a read-only version of the base on demand. This 
136
 
was implemented as part of ``trampoline`` and used a secondary program 
137
 
``timount`` (see :file:`bin/timount/timount.c`) run at regular intervals to 
138
 
unmount unused jails. This uses the :const:`MNT_EXPIRE` flag for 
139
 
:manpage:`umount(2)` (available since Linux 2.6.8) that only unmounts a 
140
 
directory if it hasn't been accessed since the previous call with 
141
 
:const:`MNT_EXPIRE`.
142
 
 
143
 
While quite effective, AUFS appears to cause NFS caching issues when IVLE is 
144
 
run as a cluster as well as questionable inclusion status in newer 
145
 
distributions. The current system used in IVLE the much older *bind mount* 
146
 
feature which allows directories to be accessible from another location in the 
 
129
user's local home directory with the base image.
 
130
To achieve this, IVLE uses the *bind mount* feature of Linux, which allows
 
131
directories to be accessible from another location in the 
147
132
file system. By carefully read-only bind mounting the jail image and then bind 
148
133
mounting the user's :file:`/home` and :file:`/tmp` directory data over the top 
149
134
we can create a jail with only three bind mounts and at virtually no 
150
135
filesystem overhead.
151
136
 
 
137
.. note::
 
138
   IVLE has historically used numerous solutions to this problem, which are
 
139
   chronicled here to avoid the same mistakes being made again.
 
140
 
 
141
   In the first release of IVLE this was done off-line by hardlinking all the
 
142
   files into the target directory, but for more than a handful of users this
 
143
   process could take several hours and also ran the risk of exhausting inodes
 
144
   on the underlying file system.
 
145
 
 
146
   The first solution was to use  `AUFS <http://aufs.sourceforge.net/>`_ to
 
147
   mount the user's home directory over a read-only version of the base on
 
148
   demand. This was implemented as part of ``trampoline`` and used a secondary
 
149
   program ``timount`` (see :file:`bin/timount/timount.c`) run at regular
 
150
   intervals to unmount unused jails. This uses the :const:`MNT_EXPIRE` flag
 
151
   for :manpage:`umount(2)` (available since Linux 2.6.8) that only unmounts a
 
152
   directory if it hasn't been accessed since the previous call with
 
153
   :const:`MNT_EXPIRE`.
 
154
 
 
155
   While quite effective, AUFS appears to cause NFS caching issues when IVLE
 
156
   is run as a cluster as well as questionable inclusion status in newer
 
157
   distributions. This is why the current system uses the much older bind
 
158
   mount feature to achieve the same ends.
 
159
 
152
160
Entering the Jail
153
161
-----------------
154
162