Date:	Sat, 9 Aug 2014 18:17:10 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Li Xi <pkuelelixi@...il.com>
Cc:	linux-fsdevel@...r.kernel.org,
	Ext4 Developers List <linux-ext4@...r.kernel.org>,
	viro@...iv.linux.org.uk, hch@...radead.org,
	Jan Kara <jack@...e.cz>, Andreas Dilger <adilger@...ger.ca>,
	"Niu, Yawei" <yawei.niu@...el.com>
Subject: Re: [PATCH v2 0/4] quota: add project quota support

An additional philosophical question.  If your argument is that you
want project quotas to be as fully general and to work like group
quotas --- then this brings up a fundamental question --- why can't
you just use group quotas?

What is the use case where you need to have two different quotas that
work exactly like group quotas?  And following in the general design
rule of "Zero, one, or infinity: there is no two", for whatever use
case where you might argue that you need _two_ quotas with identical
semantics as group quotas, who is to say that there won't be someone
that comes up with some other use case where you need _three_ quotas
with identical semantics as group quotas.  Or _four_ group quotas
being tracked simultaneously.  Etc, etc., etc.

The advantage of doing the directory hierarcy based quota system is
not just that it's compatible with XFS; it is that it is *different*
from group quotas.  Not more restrictive, but *different*.  There will
certainly be scenarios where someone wants to enforce a restriction on
the size or number of inodes in a directory hierarcy, and where when
you move a file out of a directory hierarcy into another one, you
*want* the usage quota to be transfered from the source to the
destination hierarcy.

It may not be what *you* want, but let me ask you this --- why is it
that you can't use the group quota system, and need to invent an
entirely new project quota?  The only excuse I've heard is for people
who are doing container virtualization.  I don't know if that's your
reason, but let's examine that use case in detail.  The reason why the
container virtualization folks want project quotas is because they
want to have quotas imposed on a portion of the directory hiearchy
that is given to a customer to use in a chrooted container-style "VM".
And since the user is going to be using their own user and group id's,
virtualized using the user and group namespaces, they need a third
dimension, called project id's.  

That's all very fine and good, but if you make it fully general, where
support for it is in ls, find, a new "chproj" command, etc., it start
becoming an attractive nuisance which either systemd or GNOME might
start using for their own nefarious purposes.  And once they start
using that, and it's incorporated into a Fedora release, now someone
who wants to run Fedora inside a container, and use project id's for a
quota system for a container, will collide with the use of project
id's for Fedora!   Oops.

And this is where the "zero, one, or infinity" rule comes into play.
You can either keep project quotas very tightly constrained for a
single use case --- namely, virtualization for containers, in which
case what you want really *is* based on directory hierarcies --- or
you make it be something fully general, where these different quota
types are stored as extended attributes, so you can have multiple
different namespaces --- one for the Parallel's container group name,
for the container quota system; another one for the GNOME use of the
"project quota", and so instead of having a single "project quota"
inode, let that reserved inode be used for a directory, so you can
have multiple "quota inodes" for the different dimensions of quota
usage.

Personally, I think this latter approach is way too complicated, and
I'd much rather implement a single directory hierarcy based quota
system which is compatible with XFS and has XFS's semantics.  But at
least this second approach is *fully* general, if you are going to
argue for a more general solution.

Regards,

					- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists