OmegaPhil: > I've gone through this procedure - everything is fine. This is as > expected as originally I said this problem only arose when the aufs > volume was mounted at boot via fstab - when you do it later on > everything is fine.
Then what will happen if you put 0 - 6 steps just before mounting aufs from fstab in rc scripts? And what is the refcount just after processing fstab? Is it incemented unexpectedly? > Would you agree that me continuing the original kernel tracing at an > earlier stage would be the best way to proceed? Assuming the refcount is unrelated to your original EBUSY problem, I am joining with you and thinking how to identify when the refcount is incremented. Isn't it enough to put lsmod or "cat /sys/module/aufs/refcnt" in rc scripts? Ah, probably you did it already too. Then when and what command incremented the refcount unexpectedly? Or if it is easy for you to build kernel, inserting printk() just after every these calls may be helpful. But I don't know how it is better than your trace-cmd. __this_cpu_write(mod->refptr->incs, 1); __this_cpu_inc(module->refptr->incs); __this_cpu_inc(module->refptr->decs); J. R. Okajima ------------------------------------------------------------------------------ Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/
