[zack.kirsch@isilon.com: RE: [PATCH]: Windows BRL Try 2]

[Jeremy Allison]

----- Forwarded message from Zack Kirsch <zack.kirsch at isilon.com> -----

Subject: RE: [PATCH]: Windows BRL Try 2
From: Zack Kirsch <zack.kirsch at isilon.com>
To: Jeremy Allison <jra at samba.org>

>> What exactly do you mean by complicated lockingX logic ?

I'm referring to the logic that decides whether or not to defer a lock:

if (br_lck && blocking_lock && ERROR_WAS_LOCK_DENIED(status)) {

        /* Windows internal resolution for blocking locks seems

           to be about 200ms... Don't wait for less than that. JRA. */

        if (lock_timeout != -1 && lock_timeout < lp_lock_spin_time()) {

                lock_timeout = lp_lock_spin_time();

        }

        defer_lock = True;

}

 

/* This heuristic seems to match W2K3 very well. If a

   lock sent with timeout of zero would fail with
NT_STATUS_FILE_LOCK_CONFLICT
   it pretends we asked for a timeout of between 150 - 300 milliseconds
as    
   far as I can tell. Replacement for do_lock_spin(). JRA. */

 

if (br_lck && lp_blocking_locks(SNUM(conn)) && !blocking_lock &&

                NT_STATUS_EQUAL((status), NT_STATUS_FILE_LOCK_CONFLICT))
{    
        defer_lock = True;

        lock_timeout = lp_lock_spin_time();

}


The issue here is that the decision to do an async lock is done after
trying a 
synchronous lock. As the code currently lies, doing an async lock
depends on the
return status of the sync lock call.

I think it would be a cleaner abstraction if we know whether we're okay 
doing an async lock from the beginning (i.e. when the sync-lock call is
made.)
Only paths that absolutely want no async locking would call into 
BRL_LOCK_WINDOWS_SYNC(), whereas paths that are okay with an async setup
would
call into BRL_LOCK_WINDOWS_ASYNC(). LockingX would then call one or the
other,
not both.

The benefit for OneFS is related to the kernel API that I created: When 
Samba calls the ifs_cbrl(LOCK) syscall on our system, it passes in
whether its
okay doing it asynchronously. However, using the current abstraction
I've
created in Samba, OneFS will end up doing an ifs_cbrl(LOCK, noasync)
syscall 
and then an ifs_cbrl(LOCK, async) syscall -- when it only needed to make
a single
syscall.

Does this make more sense?

Zack

----- End forwarded message -----