Jorgen,
Thank you for sending logs.
Let's change the thread and continue the discussion a little more.

I think that make the xino files to be persistent is most hopeful, but
it may be difficult to ensure the branch set is perfectly the same.

With the persistent xino files will allow you to:
# mount -t aufs -o br:<branch set A>,keep_xino none /aufs
# umount /aufs and keep the xino files
# mount -t aufs -o br:<branch set A>,use_old_xino none /aufs

But if you give different branch set to the second aufs mounting, you
may be totally lose since it is hard to judge the correctness of
matching xino files and the branch set.
The uuid on a filesystem may be helpful, but the recent vmware/xen users
may not pay attentions to uuid. If the uuid is illegally set to the
branch fs, it must be useless.

About the approach you wrote which is to make nfs client to re-lookup
the inodes after rebooting, I am afraid it means nfs server will return
ESTALE for almost all accesses, and the nfs-root client will not work
anymore.


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/

Reply via email to