Re: [9fans] More venti sync woes.

[Kernel Panic <cinap_lenrek@gmx.de>]

Russ Cox wrote:

>dma is worth around 10x, certainly less than 50.
>i agree that your venti server is taking a very long
>time to come back.  i reboot mine all the time
>and don't have this problem.
>
>i am at a loss for what could be taking it so long.
>it's probably not going to hurt any to stop it.
>it could take forever -- maybe it's looping!
>
>
It is...

while(1){
proc main: kick icache
work icachewritecoord: start
proc icachewritecoord: icachewritecoord kick dcache
work flushproc: start
proc flushproc: build t=131
proc flushproc: writeblocks t=991
proc flushproc: writeblocks.1 t=1632
proc flushproc: writeblocks.2 t=2296
proc flushproc: writeblocks.3 t=2944
proc flushproc: undirty.4 t=3564
work flushproc: finish
proc icachewritecoord: kick dcache
proc icachewritecoord: icachewritecoord kicked dcache
proc icachewritecoord: icachewritecoord start flush
proc icachewritecoord: icachedirty enter
proc icachewritecoord: icachedirty exit
proc icachewritecoord: icachewritecoord sleep
proc main: kick icache
}

the main proc loops in icachealloc():

while(icache.ndirty == icache.entries){
	/*
	 * This is a bit suspect.  Kickicache will wake up the
	 * icachewritecoord, but if all the index entries are for
	 * unflushed disk blocks, icachewritecoord won't be
	 * able to do much.  It always rewakes everyone when
	 * it thinks it is done, though, so at least we'll go around
	 * the while loop again.  Also, if icachewritecoord sees
	 * that the disk state hasn't change at all since the last
	 * time around, it kicks the disk.  This needs to be
	 * rethought, but it shouldn't deadlock anymore.
	 */
	kickicache();
	rsleep(&icache.full);
}

but icache.ndirty never changes... so it hangs forever in
"sync..." because it cant allocate ientries.

>when you manage to boot in other means,
>it would be nice to see what ps -a|grep venti
>says.  venti sets its proc args that show up in ps -a
>to tell you what each proc does.
>
>the new venti is very careful both about the
>consistency of what is stored on disk and about
>recovering quickly after a disk failure
>(there's not a lot to do -- just pick up the unindexed
>arena entries from the arena tocs and toss them
>back into the index write buffer where they were
>when you restarted the system).
>
>what you're describing could happen if you were
>running a new venti (which buffers index updates
>quite aggressively) and then on reboot managed
>to start an old venti (which would then process the
>unindexed new blocks one at a time instead of
>buffering the updates, with about 3 seeks per block).
>
>without more information i'm afraid i have no good answers.
>
>russ
>
>
>