"Jrgen_P._Tjern":
> > Well, it is interesting to me.
> > I will consider again later while it may not be within this year.
> Ok, thanks. :-)
How do you think this approach?
- current xino files share one filename. the name is specified by xino
option or given by default. aufs creates the file per a branch and
unlink it. additonally aufs create one more xino file for an inode
number bitmap.
- introduce a new branch attribute, named brxino. its syntax is
<branch path>+<RO | RW>+brxino=<xino path>
the specified xino file will not be unlinked.
- introduce a new option, xib=<path>. this spcifies an inode bitmap, and
the file will not be unlinked.
Ex)
# mount -t aufs -o xib=/xino/for/aufs_mntpnt, \
br:/branchA=rw+brxino=/xino/for/branchA \
:/branchB=ro+brxino=/xino/for/branchB \
none /aufs_mntpnt
- when the xib option is specified, brxino must be given for all
branches.
- the xino option is un-usable when xib or brxino is specified.
I gave up assigning the xino filename automatically based upon uuid or
something.
So the filename is entirely user's choise and responsiblity. :-)
If he/she type a wrong filename, aufs inode numbers will be perfectly
crazy. So these options are dangerous.
> Well, I need some kind of quick fix, even if it's a local hack; The NFS
> server is way more important for everyday service than the NFS clients
> (no problem if they have to be rebooted, but it's a problem if the NFS
> server has to be rebooted).
I see.
But now I have a temporary part time job for my daily food.
Please wait for a while.
Junjiro Okajima
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
