>
> Or are you really saying you really need to simultaneously track quota
> from a group perspective, and a project perspectively, at the same
> time? If so, why?
An reason that we don't want to use group quota for project use case is that
we don't want to lose the track of the group usage that the user belongs
to. Let's assume GROUP1 has only two users, USER1 and USER2. Normally, we
want to query the disk usage of GROUP1 by 'quota -g GROUP1 -v'. The disk
usage should be the sum of 'quota -u USER1 -v' and 'quota -u USER2 -v', if
we never do any unusual chgrp/chown. But if we change the GID of files
created by USER1 to PROJECT1, there will be a mismatching between
'quota -g GROUP1 -v' and ('quota -u USER1 -v' + 'quota -u USER2 -v').
As mentioned by Ihara, project quota support for ext4 is an important
part of project quota support for Lustre. I'd like to explain a little
bit about the expecting usage of project quota for Lustre.
As a distributed file system, Lustre is able to use hundreds of seperate
ext4 file systems to store its data as well as metadata, yet provides a
united global name space. Some of users start to use SSD devices for better
performance on Lustre. However as we can expect, they might want to replace
only part of the drivers to SSD, since SSD is expensive. That means, part
of the ext4 file systems are using SSD and the other part of the ext4 file
systems are using hard disks. In the sight of Lustre, users can choose to
locate files on SSDs or hard disks using features of Lustre, namely 'stripe'
and 'OST pool'. Here comes the problem, how to limit the usage of SSD since
all end users want good performance badly?
Quota system is designed to allot such kind of limited resources. However,
unfortunately, former UID/GID based quotas won't help in this case. UID/GID
based quotas works well in alloting one determined kind of resource, i.e.
global space and inode usage. But when the resource itself have to be
devided to seperate parts either for management reasons (e.g. virtualization)
or physical reasons (e.g. SSD v.s. hard disk v.s. tape), UID/GID based quota
is not helping, simply because UID/GID is not a suitable way to distinguish
resources. That is why we need another dimension of quota.
Of course, we might be able to find some walk-around ways using group quota.
However, because the owners of the files can change the group attributes
freely, it is so easy for the users to evade the group quota and steal the
tight resources. For example, in order to steal SSD space, a user can just
creating the files using the sepcific group ID and then change it back.
And administrators can never expect users will cooperate on this. Users always
have enough excuses to ignore requirements from administrators to delete
unnecessary data on a shared file system, if there is no hard quota
limits on that system. In the current implementation of project quota,
project ID can only be changed by privileged users, so that won't be a
problem for it.
Thanks,
Li Xi
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
