Optimizing open_file_ntcreate()

[Jeremy Allison]

On Tue, Jul 25, 2006 at 01:35:19PM +0200, Volker Lendecke wrote:
> Hi, Jeremy!
> 
> To tune open_file_ntcreate() I would like to reduce the time
> spent under the lock. In particular with cluster stuff this
> might become a major bottleneck, there locking/messaging is
> slower and we want to scale to much bigger server setups :-)

"might" become worries me :-). But I tend to agree, I'm sure
you could get the numbers to prove it :-).

> There is one case that can be optimized I think: When there
> is exactly one opener of the file. If we figure out that the
> share_lock we just fetched and locked is fresh, we enter our
> share mode and release it again.
> 
> We open the file, possibly truncate it and set the ACL and
> so on, all without the lock being held. To get rid of all
> the races that you might think of, and idea would be to
> initially create the share mode as an exclusive one,
> functioning similar to an oplock on the share mode as such.
> The share_mode_lock would then look like:
> 
> struct share_mode_lock {
>         const char *servicepath; /* canonicalized. */
>         const char *filename;
>         SMB_DEV_T dev;
>         SMB_INO_T ino;
>         int num_share_modes;
>         struct share_mode_entry *share_modes;
>         UNIX_USER_TOKEN *delete_token;
>         BOOL exclusive_share_mode; /* The holder of the only share mode entry
>                                     * can assume it is
>                                     * alone. */
>         BOOL delete_on_close;
>         BOOL initial_delete_on_close;
>         BOOL fresh;
>         BOOL modified;
> };
> 
> A second opener of the file would detect the
> exclusive_share_mode flag and send a message to the only
> share mode entry owner, deferring the open.
> 
> The only thing that the exclusive owner has to do is to get
> the share mode, reset that flag and reply. The reply
> triggers an open retry.
> 
> I need to think more about whether we can combine the
> "exclusive_share_mode" flag with the oplock code, maybe
> adding a special oplock type.
> 
> I think this might not only help the cluster case, it might
> also reduce contention on the share mode db on a normal
> setup. In the cluster case we could implement tridge's
> suggestion that we implement acquiring the initial exclusive
> lock in a central lockd, working with a single round-trip
> instead of two ones.
> 
> Comments?

This is subtle code, difficult to modify. Can we have a call
about this ? I'm on calls etc. until 11am today. After that ?
(or sometime tomorrow).

Jeremy.