Hi,
You should test it first too. I tried this setup a few years ago with NFS4
and found it to be extremely unstable with 2 clients already.
I ran into locking errors even for read-only branches. Also you need NFS
support for Aufs in your kernel, which may (not) be a problem for you.
(Debian doesn't have it).
You could consider Aufs on iSCSI as an alternative.
Best of luck,
Thomas Dekker
On Tue, Jul 2, 2013 at 2:54 PM, Gaëtan Harter <[1]gaetan.har...@inria.fr>
wrote:
Hi aufs-users,
I work for a research platform where users can reserve embedded Linux
nodes and run what they want on them.
I'm wondering if aufs is the right tool to solve my problem, and if it
does, what configuration should I use.
Let me explain what I want to do.
I'm targeting hundreds of embedded Linux boards mounting their
file-system via NFS.
The goal of this file-system is to be shared amongst all the boards of
one user.
That means, if I install a packet on one board, it's installed on all
the others, and in term of disk usage on the server, it's scalable.
All the "dynamic" files, are stored in tmpfs, so there is no conflict.
This is the simple part, it's currently working.
Now the beginning of more complex problems.
99% of the file shared between bords, and 1% board specific
===========================================================
Iwould like to have some files different between each board.
Like the 'hostname' file, some board specific configuration files.
That'swhy I would like to use aufs, this would make a mount where I mount:
board_specific_files -> RO |----> Board_specific_mount_folder-->
mounted via nfs
linux_basic_image -> RW |
And this, for 200 hundreds of board.
(actually 800, but for the 600 remaining, the linux image might even be
read only as not given to the users)
Questions
---------
How would aufs behave in this case?
If one board modifies a file, it's modified in the 'RW' branch, but will
the other ones see the modification?
Will it be considered as a "User's Direct Branch Access"?
Do I need to set it to 'ubda=notify' for all the image?
Will each file be monitored by libnotify 200 times (I for each aufs
mount)?
If it should be mounted as 'ubda=notify', a performance improvement can
be to change to
board_specific_files -> RO |----> Board_specific_mount_folder-->
nfs
linux_basic_image -> RO |
image_difference -> RW |
Where the differences with the original image would be stored in a
separate branch to limit the number of involved files.
Does this makes sense for aufs? (it depends on the previous answers I
think)
Final goal: 97% shared, 1% board specific and 2% that might be modified
by direct branch access
==========================================================================
=====================
Now another problem, we would like to give access to a user home folder
directory on the board.
It could also be mounted via nfs afterward, but if it can be done with
aufs in the same time, it would be great.
board_specific_files -> RO|----> Board_specific_mount_folder-->
nfs
linux_basic_image -> RO |
image_differences -> RW |
home_directory_subfolder -> RW |
I would mount the home_directory_subfolder with 'ubda=notify'.
In this case, I would need to pay attention to the subfolder hierarchy,
so that files modified in the subfolder on the board, will be modified
too.
If I cannot guaranty the subfolder hierarchy the other solution would be
to do a bind mount of the home directory subfolder into the
"image_difference" folder.
What do you think of this "final" solution ?
For the moment, I didn't tested any union related stuff, I'm still
reading documentation.
And as I read documentation I find hot-spots that might cause problem,
but nothing is said about them in the man-page.
Hoping you can answer some of my questions, and if not, please let me
know too.
Thank you in advance,
Regards,
Gaëtan
--------------------------------------------------------------------------
----
This SF.net email is sponsored by Windows:
Build for Windows Store.
[2]http://p.sf.net/sfu/windows-dev2dev
References
1. mailto:gaetan.har...@inria.fr
2. http://p.sf.net/sfu/windows-dev2dev
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
