On Tue 16-02-10 08:31:48, Dmitry Monakhov wrote: > Currently only USER/GROUP quota are supported bu linux quota > But sometimes it is reasonable to have other types of quota > For example: > 1) project_id in XFS > 2) container_id in container(chroot) solutions. > This patch series is aimed to extend quota interface to support > different quota types. Last patch add the SUBTREE quota type. > This patch series does not contain fs-related part of > subtree-quota-type support. This is because generic subtree > support is relatively independent from quota part. > And in fact patches depends on two different devel trees > linux-fs.2.6 and ext4.git. So i've divided big subtree patchset > in to generic fs-related and quota-related parts. > > First tree patches performs necessary cleanup work, And > the last one extends quota to support new quota's type. > > Changes from v1: > - fixes suggested by Jan Kara > - redesign get_id() callback. Initially i've overlooked a quota transfer > case. We have to pass new id's array to get_id() and it will return > corresponding quota id. > - fix hard-coded values in dquot_initialize() Dmitry, I like the first two patches now so I've merged those. About the other two: I was thinking about what you and Christoph wrote. My conclusion was that maybe you are trying to mix two different features into one. If I understand it right, one of your requirements is that you want to limit the amount of space some subtree (container in your case) uses. This is exactly what XFS project quota does. Another requirement which I see as a different feature is that you want a separate accounting of quotas for each user / group in each container. And your intention is to implement this feature by remapping uid to (tree_id << 32 | uid) for quota purposes. Right? The trouble with your uid / gid mapping is that you would need 64-bit ids but kernel-userspace interface (quotactl) takes just a 32-bit value. So you cannot use this interface for getting and setting quota limits. At least not in the obvious way. Also I think having tree_id explicitely separated from uid / gid might make things clearer. We would store it in dquot, compare it in dqget and quota formats that are able to handle tree_ids (none currently ;) would decide how to store all the information. 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
