On Fri, Mar 21, 2008 at 02:08:47PM +0000, David Flynn wrote:
> On 2008-03-21, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >> /tmp on /tmp type tmpfs (rw)
> >> aufs on /var type aufs (rw,xino=/tmp/var/.aufs.xino,br:/tmp/var=rw:/var=ro)
> >> aufs on /etc type aufs (rw,xino=/tmp/etc/.aufs.xino,br:/tmp/etc=rw:/etc=ro)
> >> /tmp on /tmp type tmpfs (rw)
> >
> > Because this order is important, let me make sure first.
> > - both of your writable branches are the single same tmpfs
> > - both of your readonly branches are nfs, and aufs is over-mounted
> > - these writable branches are all hidden by later over-mounting tmpfs
> 
> Correct.

this appears to be same problem i am having round here. I have some ideas of
what could cause this.

Catching up, you have a /var RO via NFS, AND this /var is in you by the
machine that exports this NFS, right?!

My guess is:
 - If you rotate some /var/log at base machine (that one that exports /var
   via nfs) WHILE you are reading a non-midified file at AUFS, may cause
   this unexpected 'error'.
 
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).

I'd like you to rotate some files, or if you have /var/cache shared too (as
it appears to be the case), run some kind of /etc/cron.daily/man-db at the
aufs machine, while you delete or modify some files at /var/cache/man/ , my
hope is that we get a problem and you don't lose your var/log to store aufs
debug and sysreq from Junjiro.

Hope this can speed up problems =)

> 
> > And please check your kernel log if something was left there.
> 
> Nothing other than the aufs version number.
> 
> > This trace shows that a process is waiting for read-write semaphore will
> > be released. ... Will you show me the whole output of these?
> 
> Yes, there will be a short delay while i wait for it to happen again.
> 
> Thanks,
> 
> ..david
> 
> 
> -------------------------------------------------------------------------
> 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/

-- 
Bruno Ribas - [EMAIL PROTECTED]
http://web.inf.ufpr.br/ribas
C3SL: http://www.c3sl.ufpr.br 

-------------------------------------------------------------------------
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/

Reply via email to