2012/11/28 Jeff Layton <jlayton@xxxxxxxxxx>: > On Wed, 28 Nov 2012 18:07:46 +0400 > Pavel Shilovsky <piastry@xxxxxxxxxxx> wrote: > >> 2012/11/28 Jeff Layton <jlayton@xxxxxxxxxx>: >> > On Wed, 28 Nov 2012 17:55:41 +0400 >> > Pavel Shilovsky <piastry@xxxxxxxxxxx> wrote: >> > >> >> 2012/11/28 Jeff Layton <jlayton@xxxxxxxxxx>: >> >> > There's also a lot of logic around what sort of locking you're doing >> >> > here too. I think we ought to do the same sort of I/O regardless of >> >> > whether POSIX locks are being used or not. >> >> >> >> We can use cifs_writev for both POSIX and mandatory variants but I >> >> divided them to make POSIX variant work faster (no need to check hold >> >> a semaphore, walk through a lock list, etc). >> >> >> > >> > Refresh my memory -- why do we need to handle writes differently when >> > POSIX vs. non-POSIX locking is in force? It seems to me that that >> > shouldn't matter and the behavior should be solely a function of what >> > sort of oplock you have. >> >> A write request can have conflict with mandatory locks set on a file. >> That's why we need to check for lock conflicts before issue the >> write/read. >> > > Hmmm...and the server might not know about the lock if it's cached. > Fair enough. Yes. Also there may be a situation when we have oplock level II and brlocks sent to the server (we can only cache brlock in exclusive oplock case): we can check locks locally too and don't send a write to the server if conflicts exist - save performance. -- Best regards, Pavel Shilovsky. -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
