[CentOS] unfsd scalability issues

Les Mikesell lesmikesell at gmail.com
Sat Jun 2 18:45:38 UTC 2012


On Sat, Jun 2, 2012 at 1:31 PM, Boris Epstein <borepstein at gmail.com> wrote:
>>>
>> Anything that needs atomic operations is difficult to scale.  Throw in
>> distributed components and an extra user/kernel layer and there are
>> lots of ways to go wrong.
>>
>
>>
> Les, what doesn't need atomic operations?

That's the driving force behind 'nosql' databases.  Riak, for example
allows concurrent conflicting operations on a potentially partitioned
cluster and figures it out after the fact.  But in anything resembling
a filesystem the directory operations have to be atomic.   If you open
a file, you need to know if that name already exists, and no matter
how many processes try to create a new file or link, only one can
succeed.   So, you pretty much have to lock all directory operations
while any of them complete.  Do you happen to have a lot of files in a
single directory?

> And how doing things in kernel
> makes your program more scalable - it is the algorithm that matters, not
> the execution space, IMO.

It is hard enough to do atomic operations and locks at a single layer
- it becomes next to impossible when distributed, and adding layers
with different scheduling concepts has to make it worse.  The kernel
has its own way of locking, but anything in userland is going to need
a trip into the kernel and back just for that.

-- 
   Les Mikesell
    lesmikesell at gmail.com



More information about the CentOS mailing list