7 Commits

Author	SHA1	Message	Date
Tim Prouty	7424665061	s3 onefs: Add missing newlines to debug statements in the onefs module	2009-03-31 17:31:50 -07:00
Zack Kirsch	bfc7bb49ff	s3 onefs: Async failures are resulting in SMB_ASSERT->smb_panic while running many of the LOCK torture tests. ... Return true from the onefs cancel function if we've errored, which can happen when the CBRL domain is configured to only give out 1 lock. :)	2009-03-31 17:29:07 -07:00
Dave Richards	5df46fa35b	s3 OneFS: Add kernel strict locking support	2009-03-13 14:21:40 -07:00
Tim Prouty	664268a287	s3 OneFS: Refactor config code and cleanup includes	2009-03-01 16:39:55 -08:00
todd stecher	95bf60b39d	S3: Add in profile counters for new vfs and syscall entries.	2009-02-24 15:53:01 -08:00
Zack Kirsch	053e1873c5	s3: OneFS: Pass in the client's fnum to the ifs_cbrl syscall.	2009-02-18 20:50:05 -08:00
Zack Kirsch	a3531314dd	OneFS implementation of BRL VFS ops: ... * Much of the beginning should look familiar, as I re-used the OneFS oplock callback record concept. This was necessary to keep our own state around - it really only consists of a lock state, per asynchronous lock that is currently unsatisfied. The onefs_cbrl_callback_records map to BLRs by the id. * There are 4 states an async lock can be in. NONE means there is no async currently out for the lock, as opposed to ASYNC. DONE means we've locked *every* lock (keep in mind a request can ask for multiple locks at a time.) ERROR is an error. * onefs_cbrl_async_success: The lock_num is incremented, and the state changed, so that when process_blocking_lock_queue is run, we will try the *next* lock, rather than the same one again. * onefs_brl_lock_windows() has some complicated logic: * We do a no-op if we're passed a BLR and the matching state is ASYNC -- this means Samba is trying to get the same lock twice, and we just need to wait longer, so we return an error. * PENDING lock calls happen when the lock is being queued on the BLQ -- we do async in this case. * We also do async in the case that we're passed a BLR, but the lock is not pending. This is an async lock being probed by process_blocking_lock_queue. * We do a sync lock for any normal first request of a lock. * Failure is returned, but it doesn't go to the client unless the lock has actually timed out.	2009-02-13 10:08:55 -08:00