Re: [9fans] kfs locks

[Charles Forsyth <forsyth@terzarima.net>]

[-- Attachment #1: Type: text/plain, Size: 497 bytes --]

the intent is that the sync command ensures that all current IO has gone
to disc without allowing file system activity
meanwhile--that's what the rlock of mainlock does--
but syncproc is allowed to run
concurrently with file system activity
to encourage the disc to be reasonably up to date
but without ensuring it.
there are interlocks on the buffers themselves (for instance)
to prevent confusion between several processes active
at once, whether for file system activity or syncproc.

[-- Attachment #2: Type: message/rfc822, Size: 2490 bytes --]

From: David Tolpin <dvd@davidashen.net>
To: 9fans@cse.psu.edu
Subject: [9fans] kfs locks
Date: Sun, 7 Mar 2004 21:55:37 +0400 (AMT)
Message-ID: <200403071755.i27HtbcR080605@adat.davidashen.net>

Hi,

cmd_sync sets 

rlock(&mainlock); 

...
syncall();
...
runlock(&mainlock);

...
syncproc, the background process forked by kfs, runs 
syncblock()
without setting rlock(&mainlock)

Can it the cause that I am getting wrenwrite errors after
'check f' on startup, if cmd_sync is not called after cmd_check
and before forking 'sync' and 'serve'?

I am still struggling to understand the problem. I've changed
the disk to be sure and still can reproduce the error if cmd_sync
is not called after the list of free blocks is rebuilt after blackdown.

David Tolpin