Re: [PATCH 0/11] RFC quota scalability V1

[Jan Kara <jack@suse.cz>]

On Wed 06-10-10 14:15:38, Dmitry wrote:
> > > >  quota: add wrapper function
> > > >  quota: Convert dq_state_lock to per-sb dq_state_lock
> > > >  quota: add quota format lock
> > > >  quota: make dquot lists per-sb
> > > >  quota: make per-sb hash array
> > > >  quota: remove global dq_list_lock
> > > >  quota: rename dq_lock
> > > >  quota: make per-sb dq_data_lock
> > > >  quota: protect dquot mem info with objects's lock
> > > >  quota: drop dq_data_lock where possible
> > > >  quota: relax dq_data_lock dq_lock locking consistency
> >   So one generic question: I see you split global locks into per-sb ones.
> > Does it bring substantial advantage? Because from my experience common
> > systems have just one or maybe two filesystems which are heavily used...
>   It was so in the past, but currently hardware is too powerful for single
>   system. Today is the age of virtual environments (containers, cgroups,
>   etc).  Usually each VE has it own filesystem. And people do care about
  OK, in the virtualization environments I've seen, they usually used a
single filesystem as a backing store for fs images. I imagine that if you
use containers, you may have incentive to have a separate fs for each
container although I thought that people used bind mounts and such stuff
in these cases - I've never seen a real system using containers ;). Anyway
if you know about systems that would take advantage of your split then I'm
OK with that. The split does not harm the single fs case and is simple
enough...

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR