[Unionfs] unionfs beginner's question

[Jesse I Pollard]

Stephan Schöffel wrote:
> hi there,
>
> i'm new to unionfs and have to evaluate it for work. i'm not quite 
> sure how to begin or even how to install unionfs. on 
> http://www.fsl.cs.sunysb.edu/project-unionfs.html i found a tarball 
> containing version 1.4. alternatively, i downloaded a version 2.x as 
> well using git and the instructions on the website.
>
> is there a way to compile the 2.x version as a kernel module as there 
> is for 1.4, since i'm not very familiar with kernel compilation.
>
> any hints on how to proceed are welcome.
>
> gtx
> stephan

It is actually not that difficult.

The usual way to do it is:

1. download the appropriate kernel tarball that matches the release 
version of unionfs

2. untar the kernel in a suitable directory (it does NOT have to be root).

3. download the unionfs into the same base directory that you put the 
kernel directory in, and decompress.

4. The unionfs code is formatted as a patch to the kernel source, so you 
add the unionfs
   to the kernel using patch. I set my working directory to the kernel 
starting point and
   use "patch -p1 <../unionfs-for-...".

5. Obtain the kernel .config file for the base configuration of your 
system. This file
   can be found for recent kernel versions in /boot/config-<version>.

6. I do a "make xconfig" (but a make menuconfig can also work) and 
examine the options.
   You will have to add unionfs to the build (I recommend a loadable 
module). You
   will find this option under "layered filesystems", with two 
suboptions - "unionfs
   extended attributes" and "debug unionfs". In my case, I have "union 
file system"
   set for module ,and both suboptions set to yes/enabled.

7. Then I can do a "make". If no errors occur (they usually don't), then 
a "make modules".
   the system is now configured for installation.

8. since my system is a red hat/centos (I don't know if the same applies 
to other
   distributions, but I think it does), I can now install the system by 
"su root" which
   will not change the working directory, and then do a "make install" 
followed by "make
   modules_install". The Kernel make file structure knows how to build 
an initrd, and
   update the /boot/grub/grub.conf files. Note: the new system is NOT 
made the default.

9. When you reboot the system you have to select the kernel to boot - I
   have found that the kernel makefile always makes the new system the 
first one in the
   list.

10. After reboot, you can setup your tests. I have been putting all the 
mounts in /mnt.


For my testing, I created three directories: /mnt/a, /mnt/b and /mnt/c. 
Since I am also
testing the odf format for use with NFS exporting the union, I also have 
a loopback mount
for the odf filesystem (still testing, I don't have a good recomendation 
for this filesystem yet).

I mount the union of a and b onto c (using the odf filesystem) by:

        mount -t unionfs -odirs=/mnt/a=rw:/mnt/b=ro/odf=/odffs none /mnt/c

This makes the /mnt/b directory a read only branch. The /mnt/a directory 
is where
files go when they are created in the /mnt/c unionfs mountpoint. If I 
put a file
in /mnt/a (say, /mnt/a/readwrite) and a file in /mnt/b (such as 
/mnt/b/readonly) and
put some random data in there, then both files will show up in /mnt/c. 
If I attempt
to update the file /mnt/c/readonly, the unionfs will copy the file from 
/mnt/b to
/mnt/a, and then allow me to update that copy. The original 
/mnt/b/readonly remains
unchanged.

The odf filesystem records my basic configuration of the mount. If I 
have a subsequent
mount with the odf filesystem then I do not need to specify the /mnt/a 
and /mnt/b
branches of the union. I can just do:

       mount -t unionfs -oodf=/odffs none /mnt/c

I don't even need to use the same target mount - If I do the same as:

       mount -t unionfs -oodf=/odffs none /mnt/d

then I get a union mount of /mnt/a and /mnt/b on a mountpoint /mnt/d. 
Note: you can't
use the same odf filesystem for two different targets at the same 
time... Using the
odf also allows me to export the target via NFS.

My goal is to support migrating from one network attached storage system 
to another.
unionfs should allow this by having a server system between the network 
storage units
and the client systems. The /mnt/a (the read write directory) represents 
the NAS unit.
The /mnt/b (the readonly directory) represents the old NAS. This gives 
the NFS client
systems the appearance of an expanded storage system without removing 
the old NAS.
My plan is to gradually move files from the old NAS to the new one while 
users are
also updating their files during normal work. Because unionfs will 
automatically copy
files opened for write/update, I only need to move really old files.

One tacky way to do it is just "find /mnt/c -depth -exec touch '{}' 
';'".... This
however, updates all file dates to the current time (not necessarily the 
best thing).