[sheepdog] [PATCH 2/4] farm: add basic concurrent support

[Liu Yuan]

On 05/18/2012 09:37 PM, Liu Yuan wrote:

> On 05/18/2012 07:34 PM, Christoph Hellwig wrote:
> 
>>> From: Liu Yuan <tailai.ly at taobao.com>
>>>>
>>>> refactor strcut siocb, this makes the code more clean, also we can call xlockf()
>>>> inside sd_store->read/write to support concurrent access.
>>>>
>>>> - let sd_store->read/write() use open() internally.
>>>> - remove sd_store->open()/close()
>>>> - add sd_store->exist()
>>>>
>>>> But now we don't actually have concurrent requests to the same object, because
>>>> upper layer have exclude concurrent access by check_request().
>>>>
>>>> We'll remove this constaint by later patch set.
>> Can you split the refactoring from the actual concurrency changes?
>>
>> Also I'd really prefer not having to call lockf twice for every single
>> I/O, the kernel file locking code isn't exacly scalable.  Any pure
>> userland locking will scale a lot better.
>>
> 
> 
> Okay, I'll drop lockf and only do the refactoring and leave the locking
> mechanism to be implemented later, for now I can't come up with a simple
> userland lock mechanism.
> 


Well, with a second thought on it, we might not have high concurrency
access to the same object. The most high I can think of is the shared
COW objects of the based image. But this is read-only, fcntl's rdrw lock
would scale up.

Compared to actual disk IO, the locking overhead can be neglected. I
think use kernel's strcut flock is simplest method, otherwise we would
keep track of a huge memory for lock structures.

Thanks,
Yuan