Thanks for your answers,
the indirect UDBA was what I was expecting.
But has the 'udba=notify' does not increase memory usage with the number of
mounts, it may still be bearable in a performance point of view.
However, I would switch to a "snapshot" mode, where only the files different
from the basic image would be monitored.
So I could still reduce the number of shared files to follow, and the memory
footprint on the server.
server# mount -t aufs -o
br:/mnt/linux_basic_image_read_only=ro,/mnt/board_1_files=ro,/mnt/image_differences_for_user_1=rw
/export/image_board_1
In my case, the mounts should only last a few hours, when the nodes are used,
the image_difference will be quite limited and can then be discarded when the
reservation is over.
I will test and present this to my colleagues to see what they think of it.
I'll tell you if I keep this solution.
Using aufs, all the configuration can be done on the server, and the linux
board boots on the final image.
But it make a more complex infrastructure with a union filesystem, and maybe
performance for handling the shared modifications.
The other solution is to move the complexity on the board and run other nfs
mounts after startup, and some configuration in init.d files, like changing the
board hostname.
But it add complexity in the embedded board, and do "after boot" fixes to get
the final system.
Thank you.
Regards,
Gaëtan
On 07/02/2013 05:43 PM, sf...@users.sourceforge.net wrote:
> Ga tan Harter:
>> I'll try to clarify my situation.
>>
>>
>> On the server I will have the following unions, that all share the
>> /mnt/linux_basic_image RW branch
>>
>> server# mount -t aufs -o
>> br:/mnt/linux_basic_image=rw,/mnt/board_1_files=ro /export/image_board_1
>> server# mount -t aufs -o
>> br:/mnt/linux_basic_image=rw,/mnt/board_2_files=ro /export/image_board_2
> :::
>
>> Now, on client_1, if I make a modification on my filesystem.
>> It will propagate via nfs to the server, which will be catched by aufs,
>> which will update the files in /mnt/linux_basic_image branch.
>> But there are 199 other nodes also using the same branch
>> /mnt/linux_basic_image.
>>
>> Will aufs manage to seamlessly propagate the change to the others aufs
>> mounts too?
>> or will it consider that it is a UBDA for the 199 other nodes ? and I will
>> need to use 'ubda=notify'.
> I see.
> You mount many aufs-es on NFS server and export them.
> In this case, for /image_board_2, changes made to /linux_basic_image via
> /image_board_1 (regardless on server or client) is equivalent to
> UDBA, because the change is made outside of aufs-image_board_2. So you
> need "udba=notify".
>
>
>> And in the case I'd put this rw branch in "udba=notify" mode, how many files
>> will be monitored by aufs via libnotify, the actual number of files or 200
>> times the number of files ?
> Aufs doesn't use libnotify. Instead, it is done in kernel space.
> Aufs doesn't have limit to set inotify. It is limited by the number of
> VFS cached inode. When VFS thinks it becomes a memory pressure, VFS
> discards inode cache including aufs inodes. When an aufs inode is
> released, it unsets the inotify settings.
> In other words,
> - aufs inode refers to the branch inode (the inodes on
> /mnt/linux_basic_image in your case), and sets inotify. Eg. the aufs
> inode monitors the corresponding branch inode.
> - when no one referts to the aufs inode and VFS discards the cached aufs
> inode, aufs unsets inotify and decrements the reference count of the
> branch inode.
>
> Additionally aufs sets inotify for the directory only instead of every
> files. It has a good effect to reduce the number of inotify settings.
>
>
>> My problem is more on the implementation of aufs than usage.
>> It's kinda like "does aufs consider each mount separated from the others, or
>> does it share data between all mounts"
> The mounted /aufsA differs from another mounted /aufsB. Yes, aufs
> considers each mount separated from others.
>
> I'd suggest you to check
> http://aufs.cvs.sourceforge.net/viewvc/aufs/aufs/sample/diskless/
>
> It is a very old aufs sample for diskless systems and mount aufs on NFS
> client. So several things are different from current aufs. But there may
> be something you can count on.
>
>
> J. R. Okajima
>
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
