Re: LOOKUP_SHARED is default now

2002-05-06 Thread qhwt

Hi.

On Tue, Apr 09, 2002 at 01:08:04AM -0400, Jeff Roberson wrote:
 This patch has seriously reduced file system deadlocks for several people.
 It also makes concurrent file system access much faster in certain cases.
 Since I have only heard good reports and no bad reports I'm going to
 enable it by default.  If you do experience some file system deadlocks
 please let me know.  You may revert to the previous behavior with 'options
 LOOKUP_EXCLUSIVE'.  I will take this away after a month or so if there are
 no problems.

I've been struggling upgrading kernel since beginning of April, and finally
found I have to add options LOOKUP_EXCLUSIVE to my kernel config file.
Without LOOKUP_EXCLUSIVE,
 - some of the processes stall in inode state, and can't be killed
by any signals
 - shutting down(and maybe unmounting) the system results in the panic:
lockmgr: upgrade exclusive lock

The stalling processes are all touching files under nullfs-mounted
directories, so I think nullfs code is not yet LOOKUP_SHARED-safe.
If anyone is interested, I can post the backtrace and my kernel config
(after upgrading the world and rebuilding the panicking kernel).

Regards.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: LOOKUP_SHARED is default now

2002-05-06 Thread Joshua Goodall

On Mon, May 06, 2002 at 03:53:27PM +0900, [EMAIL PROTECTED] wrote:
 I've been struggling upgrading kernel since beginning of April, and finally
 found I have to add options LOOKUP_EXCLUSIVE to my kernel config file.
 Without LOOKUP_EXCLUSIVE,
  - some of the processes stall in inode state, and can't be killed
 by any signals
  - shutting down(and maybe unmounting) the system results in the panic:
 lockmgr: upgrade exclusive lock
 
 The stalling processes are all touching files under nullfs-mounted
 directories, so I think nullfs code is not yet LOOKUP_SHARED-safe.
 If anyone is interested, I can post the backtrace and my kernel config
 (after upgrading the world and rebuilding the panicking kernel).

If you're feeling experimental try the change in PR kern/37270. It
makes nullfs partially safe w.r.t. LOOKUP_SHARED, although there
are still easily reproducable deadlocks (possible interactions with
the syncer and/or vnlru processes but nothing concrete; at least,
not from me).

Joshua

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: LOOKUP_SHARED is default now

2002-04-10 Thread Sheldon Hearn



On Tue, 09 Apr 2002 15:06:19 -0400, Jeff Roberson wrote:

 Right, sorry.  There was some minimal discussion about this on arch quite
 a while ago.  Basically, it allows namei to return leafs locked with
 shared locks instead of exclusive locks when a flag is set.
 
 This not only reduces contention, but also the number of exclusive locks
 that are floating around in the system.

A good place for this to be documented is the NAMEI OPERATION FLAGS
section of the namei(9) manual page.

If you're not comfortable with the mdoc(7) markup language, you can
submit your documentation change in plaintext format to the -doc list,
and someone will usually do the markup and commit for you.

Ciao,
Sheldon.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: LOOKUP_SHARED is default now

2002-04-10 Thread David O'Brien

On Wed, Apr 10, 2002 at 12:00:13PM +0200, Sheldon Hearn wrote:
 A good place for this to be documented is the NAMEI OPERATION FLAGS
 section of the namei(9) manual page.

I don't believe this option will exist long enought for it to need to be
documented.  Jeff changed the default, but left the option incase it
unexpectedly caused problems for people.  AFAIK, the option will totally
go away RSN.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: LOOKUP_SHARED is default now

2002-04-09 Thread Dag-Erling Smorgrav

Jeff Roberson [EMAIL PROTECTED] writes:
 This patch has seriously reduced file system deadlocks for several people.
 It also makes concurrent file system access much faster in certain cases.
 Since I have only heard good reports and no bad reports I'm going to
 enable it by default.  If you do experience some file system deadlocks
 please let me know.  You may revert to the previous behavior with 'options
 LOOKUP_EXCLUSIVE'.  I will take this away after a month or so if there are
 no problems.

Considering that neither LOOKUP_SHARED nor LOOKUP_EXCLUSIVE is
documented anywhere, could you enlighten us as to what, exactly, they
do?

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: LOOKUP_SHARED is default now

2002-04-09 Thread Jeff Roberson



On 9 Apr 2002, Dag-Erling Smorgrav wrote:


 Considering that neither LOOKUP_SHARED nor LOOKUP_EXCLUSIVE is
 documented anywhere, could you enlighten us as to what, exactly, they
 do?


Right, sorry.  There was some minimal discussion about this on arch quite
a while ago.  Basically, it allows namei to return leafs locked with
shared locks instead of exclusive locks when a flag is set.

This not only reduces contention, but also the number of exclusive locks
that are floating around in the system.

Jeff


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



LOOKUP_SHARED is default now

2002-04-08 Thread Jeff Roberson

This patch has seriously reduced file system deadlocks for several people.
It also makes concurrent file system access much faster in certain cases.
Since I have only heard good reports and no bad reports I'm going to
enable it by default.  If you do experience some file system deadlocks
please let me know.  You may revert to the previous behavior with 'options
LOOKUP_EXCLUSIVE'.  I will take this away after a month or so if there are
no problems.

Thanks,
Jeff


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message