[Tails-dev] RFC: bind-mounts vs. unions for persistence

Delete this message

Reply to this message
Autor: anonym
Data:  
Dla: The T(A)ILS public development discussion list
Temat: [Tails-dev] RFC: bind-mounts vs. unions for persistence
Hi,

As part on my work to improve live-boot's persistence I have implemented
two different ways which a persistent directory on the persistent media
can be mounted in the live system's filesystem.

Here's short intro on how it works for those who doesn't want to read
the quite long RFC [1]:

Say we have a persistent $MEDIA. Say the file $MEDIA/live.persist looks
like this:

#source       #destination      #option
my_etc        /etc
dir/asdf      /home


This will make ${MEDIA}/my_etc "appear" on /etc in the live system, and
${MEDIA}/dir/asdf appear on /home.

[1] http://live.debian.net/devel/rfc/persistence/

Options can be given on the third column, and the two ones relevant for
this discussion is:

* <nothing>: The directory on the persistent storage is simply "mount
--bind":ed to the destination in the live system's filesystem.

* union: The directory on the persistent storage is the rw branch of a
union with the destination in the live system's filesystem.

So, to the question: which one we should use in Tails? Here's some
observations about the differences:

1. With unions we only save the "diff" against the live system, and this
has the potential to save a lot of disc space on the persistent media
(think persistent /usr + installed packages). It's not so useful for
e.g. /home since /home/amnesia is dynamically generated during
live-config. So this option is only useful if the mount point
occupies a lot of space on the read-only filesystem.

2. While we still have to worry about union mounts hiding stuff in the
read-only filesystem, we don't have to worry about it as much as with
bind mounts. Any changes in the read-only filesystem will be visible
through the union mount unless the user has removed or modified that
file, or added a file with the same name as some new file that's
introduced in the ro filesystem.

So, 1 isn't that interesting for us since we mostly will make
directories in $HOME persistent. 2 is interesting, especially for *.d
style configuration directories, but they are so uncommon that we cannot
rely on it. Hence bind-mounts seem to be the more sensible approach to me.

Cheers!