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@xxxxxxx> SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
