Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 15 Mar 1998 17:06:14 -0600
From:      Karl Denninger  <karl@mcs.net>
To:        Terry Lambert <tlambert@primenet.com>
Cc:        hackers@FreeBSD.ORG
Subject:   Re: Odd problem we're seeing here
Message-ID:  <19980315170614.50631@mcs.net>
In-Reply-To: <199803152212.PAA14399@usr06.primenet.com>; from Terry Lambert on Sun, Mar 15, 1998 at 10:12:59PM %2B0000
References:  <199803152155.OAA13550@usr06.primenet.com> <199803152212.PAA14399@usr06.primenet.com>

next in thread | previous in thread | raw e-mail | index | archive | help
All I got out of turning on the NQNFS mode was a near-immediate hard system
hang - no I/O, no nothing.

Needless to say, that's no good :-)

I don't know if my earlier mail got out or not, but wouldn't an effective
workaround for the cache coherency problem be to flush the attribute cache
on any flock(..., LOCK_UN) operation (either explicit or implied on file
close)?

--
-- 
Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin
http://www.mcs.net/          | T1's from $600 monthly / All Lines K56Flex/DOV
			     | NEW! Corporate ISDN Prices dropped by up to 50%!
Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS
Fax:   [+1 312 803-4929]     | *SPAMBLOCK* Technology now included at no cost

On Sun, Mar 15, 1998 at 10:12:59PM +0000, Terry Lambert wrote:
> > If you look at the code around the vn_read and vn_write, vs. the
> > code around vn_rdwr, you will see a pattern begin to emerge.
> > 
> > In all cases, when vn_read or vn_write is called, the vp is locked.
> 
> I meant "unlocked".
> 
> Right now, I am unsure of the lease code.  When I say that I think
> the vp should be locked, that's because all vp's should be locked
> before they are dereferenced to make VOP calls.  This is also why
> vp locking should be done with a vn_lock() function which locks
> the vp before it makes the VOP_LOCK call by dereferencing the vp
> to get the FS specific function.  This is also why the underlying
> VOP_LOCK should be veto-based.
> 
> Basically, if a vp is in the VOF layer (not necessarily just below
> the VFS layer, at least until Michael Hancock's VOP_VRELE), the vp
> should be locked.
> 
> Period.
> 
> This drastically simplifies a VFS consumer's view of the world.
> 
> I do not think the lease code would actually survive being called
> with a locked vp at this point because of nqnfs_lease_updatetime,
> which traverses the mountlist.
> 
> This is not something trivially fixable without a lot of controversial
> code.
> 
> Hence the punt.
> 
> Is that enough information?
> 
> 					Terry Lambert
> 					terry@lambert.org
> ---
> Any opinions in this posting are my own and not those of my present
> or previous employers.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980315170614.50631>