3 Commits

Author	SHA1	Message	Date
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