Optimizing open_file_ntcreate()

[Volker Lendecke]

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 :-)

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?

Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba-technical/attachments/20060725/2564577e/attachment.bin