Bruno Cesar Ribas: > Catching up, you have a /var RO via NFS, AND this /var is in you by the > machine that exports this NFS, right?!
I am afaid I cannot understand fully what you wrote. Do you mean that you are sharing /var between nfs server and clients? If so, I don't think it is a good idea, since generally /var is a place where host-specific data is held. For instance, files which keeps the pid of system daemons, lock-file for MTA or something. But it never mean that system freezes. Some applications will not work correctly or may stop/abort, but aufs (or kernel itself) should keep working even if files on nfs-ro branch are modified/removed on nfs server. I am afraid there may exist an unknown problem in aufs. > I'm saying that because I got some trouble at /var/cache/man , when I base > machine ran cron jobs to recreate caches AND my aufs machine (which has /var > as a NFS RO) got cron jobs to cache man stoped there. And any proccess which > needed to read /var/cache/man/*something* got problem (that D state). In your case, the bug which were fixed today may be related since you have written that CONFIG_AUFS_HINOTIFY is enabled. I'd like to suggest you to - update your aufs source files - stop sharing /var (if you did it) - and find the way to reproduce a problem Junjiro Okajima ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
