On Monday 12 May 2003 08:16 pm, Steve Lord wrote:
> On Mon, 2003-05-12 at 17:48, Kelledin wrote:
> > Further details:
> >
> > I investigated sv_wait, and it seems that function/macro is
> > intended to deliberately schedule a non-interruptible
> > deadlock for as long as the platform will allow
> > (MAX_SCHEDULE_TIMEOUT). That's a pretty long time in
> > jiffies--and on platforms where long ints are 64 bits (like
> > Alpha), it's an outrageously long time.
>
> This is intended to be a wait without a timeout, not a very
> long timeout. sv_wait is being used to block one thread
> pending a signal from another thread.
In this case, I'm guessing some other thread is supposed to wake
it up when its log queue is empty (l_reserve_headq==NULL). It
invariably seems to deadlock in xlog_grant_log_space() when it
sees the queue is non-empty.
I would guess xfslogd is responsible for clearing the log queue
and waking any thread waiting on it. I'm also guessing that for
some reason, xfslogd isn't always getting the message when a new
log ticket arrives in the queue (rare, but apparently it is
occurring). And when I go kick the inode tables on the same fs
(creating or removing a file/directory), xfslogd gets that
message, then also notices the earlier stuff in the queue that
it somehow missed.
So...how exactly does xfslogd get access to the log queue, and
how does it get notified when the queue becomes non-empty?
Maybe I'm just not looking hard enough, but this doesn't seem
immediately clear from reading the source.
--
Kelledin
"If a server crashes in a server farm and no one pings it, does
it still cost four figures to fix?"
|