From owner-freebsd-hackers  Sun Sep  8 18:38:25 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id SAA12382
          for hackers-outgoing; Sun, 8 Sep 1996 18:38:25 -0700 (PDT)
Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA12375
          for <hackers@freebsd.org>; Sun, 8 Sep 1996 18:38:23 -0700 (PDT)
Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.7.5/CET-v2.1) with SMTP id BAA13241; Mon, 9 Sep 1996 01:38:08 GMT
Date: Mon, 9 Sep 1996 10:38:08 +0900 (JST)
From: Michael Hancock <michaelh@cet.co.jp>
Reply-To: Michael Hancock <michaelh@cet.co.jp>
To: Terry Lambert <terry@lambert.org>
cc: hackers@freebsd.org
Subject: Re: namei performance (was Re: FreeBSD vs. Linux 96 (my impressions))
In-Reply-To: <199609082205.PAA03751@phaeton.artisoft.com>
Message-ID: <Pine.SV4.3.93.960909102057.12629B-100000@parkplace.cet.co.jp>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

On Sun, 8 Sep 1996, Terry Lambert wrote:

> The  actual locking methodology that probaly wants to be used is seven
> state: no lock, R (read), W (write), X (exclusive), IR (intention read),
> IW, and IX.

In the current code, the lock is an exclusive lock on the directory to
prevent consistency problems.  For example, VOP_CREAT on SYSV has to do a
rescan of the directory because it doesn't lock the directory to ensure
that the file didn't get created by someone else after the lookup was
done. 

Could you walk thru this case with the above framework?

Regards,


Mike Hancock