On 05/04/2011 07:26 PM, Jeff Darcy wrote:
On 05/04/2011 12:50 PM, Edward Shishkin wrote:
> Hello everyone.
>
> I find the subject suspicious.
> See comments in the function below.
> Where am I wrong?
> Any ideas?
Hi, Edward. Nice to hear from you at last. How are things going?
Hello Jeff,
The common crypto-stuff is almost written (wasn't debugged yet).
Today I wrote the code for EOF detection and handling incomplete
block reads and suddenly took a look at the oplock translator...
Yes, there is a race here. If "thread B" does manage to do both a lock
and a read between the time that inode->gen gets incremented and when
the data actually get modified, then it would not recognize that a
conflict had occurred, and would overwrite A's data. Note that B is not
just a local thread but a remote client which would have to incur two
network round trips (the lock and the read) within that window.
Nonetheless, a race is a race . . . but that's not the only problem with
this code. Another problem is false conflicts and spurious retries
(with no guarantee of forward progress) due to the file-level
synchronization scope.
Yes, the no-progress situation is definitely possible
This includes the case where the false conflict
is a self-conflict, due e.g. to the way that the
"writeback" translator
issues parallel writes.
What is the hierarchy of translators? I haven't found any info about
this. Just put an assumption that features is going after encryption,
so that oplock can intercept lock requests issued by crypt_aes...
This is why I have suggested before that we
should probably move away from a client-side optimistic-locking/retry
Hmm... I thought that oplock works on server. At least it is set up
by the function cloudify_server() in the scripts..
model to a server-side queuing mode, so that two conflicting
read-modify-write sequences *can't* collide at the write phase. We
should probably also look at combining the mainline and "aes" code
(that's wbe issued hy it's a branch) and consider having the
read-modify-writes apply to IVs rather than actual data.
You mean encryption with counters? It will work without
any locking, but I guess we can not rely only on this mode..
I'd certainly
appreciate your thoughts on the best high-level design, if you can
find
the time.
Will try to do my best..
Thanks,
Edward.