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 |