On 05/25/2011 05:19 PM, Jeff Darcy wrote:
On 05/25/2011 11:05 AM, Edward Shishkin wrote:
>> Server-side encryption is unusable for CloudFS, as it requires
>> trust of the servers and that violates a fundamental aspect of the
>> protections CloudFS (compared to GlusterFS without it) is supposed
>> to provide. We do need to handle the concurrent-write race you
>> mention, but we must do so without keys on the server side.
>
>
> Why? IMHO Key server is a rather popular thing. It can be implemented
> in various trusted centres like commercial banks, notaries, etc.
Yes, it can, but that approach will not be acceptable in the specific
environments that CloudFS is intended to target. People who use EC2 or
Rackspace Cloud, let alone some lesser-known public cloud provider, will
not be willing to entrust the cloud provider with their keys in any way.
Any requirement that they do so will simply cause them to seek other
solutions. This is not an engineering choice; this protection of users
from a minimally trusted storage provider is a defining characteristic
of CloudFS. If you think this requirement addresses a non-existent
need, then you think CloudFS addresses a non-existent need.
> That means we can have the server
>> help with synchronization/coordination, but not with the
>> encryption/decryption itself.
>
> Queues to perform read-modify-write on the server side is a vary
> complicated thing, whereas I guess all the crypto stuff should be
> very simple..
Yes, dealing with the coordination aspect is the most difficult part of
this. That's why I sought help.
To ensure progress means to maintain a queue on the server side in
order to proceed only with "first input". The shit can happen if a
client dies and his "serial number" is lost. TBH I don't know any
ways to detect and remove such zombies. Incorrect evaluation (e.g.
with some time-out heuristic) leads to no-progress situation on the
client side. In turn, introducing a "time out" on the client size in
order to retry with a new serial number breaks all our efforts on
resolving the no-progress problem (just moves it to the different
level). Such a "bloody loop". Of course, we can set huge time-outs.
Not sure if such solution will be better than oplock..
Any ideas?
Thanks,
Edward.