-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [EMAIL PROTECTED] wrote: > I see. > Such situation is beyond my expectations or imaginations. :-) > I guess the root cause is related to the inode number in aufs. > Basically, aufs stores its inode numbers to the xino files, and the xino > files are volatile which means the xino files are totally gone after the > aufs is unmounted. Mounting aufs again with the same branches, the new > aufs will have new, different set of inode numbers. > When the nfs client accesses to nfs server by oboleted inode number, > aufs detects their inconsistency and call BUG_ON macro. > I guess this is the story of your case. Okay, I think I understand. :-)
> If it is true, the the quiestion is: does aufs needs persistent xino > files? Well, is there any other workaround for this? Can you somehow invalidate the inode number to the NFS client, so that it looks up the inode number again? I don't know if it's of any interest, but I posted the dmesg output with your patch to the other thread. Continue discussion there? Kindest regards, Jørgen P. Tjernø. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG+gKpUMzc1WGo4zgRAmrbAJ9pX54YDPe79YIXdQPSndwaNAP8DgCfcjYl EyTtbvWiW7ykZ4Mq0757fJ0= =aROT -----END PGP SIGNATURE----- ------------------------------------------------------------------------- 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/
