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).
_______________________________________________
unionfs mailing list: http://unionfs.filesystems.org/
unionfs@mail.fsl.cs.sunysb.edu
http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
