linux-ext4 - Re: [PATCH v2 0/4] quota: add project quota support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <CAPTn0cC2a1BdtH2Jjp4NoU4apqzrJdxkPK0vf0Ahq=gds0wj3w@mail.gmail.com>
Date:	Sun, 10 Aug 2014 08:38:18 +0800
From:	Li Xi <pkuelelixi@...il.com>
To:	"Theodore Ts'o" <tytso@....edu>
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

> There is a very big and fundamental difference about project id's
> versus user/group id's, and that is that project id's are not first
> class objects in the file system.  That is, stat() doesn't understand
> them.  Processes do not belong to one (or more) projects, the way they
> do for user and group id's.
Yeah, I totally agree that project ID is different from UID/GID in this
sense. And I think it happens to be why we need project quota rather than
using existing group quota actually.
>
> As a result, project id's are a massive administration nightmare.  You
> can't easily see which project a file belongs to, since "ls" and
> "stat" has no support for the project id.  So if a file is created in
> one directory, the file will inherent that project id from its parent
> directory.  Suppose that file is 100 gigabytes, and it chews up most
> of the project quota for that project.  Now suppose that file is moved
> to some other directory.
>
> How in the world is the administrator supposed to find the file which
> is chewing up 100GB of quota?  Find doesn't support project id's
> either....
That is the same problem when we are scattering inodes with different
UID/GID into directory-trees. I don't think there is any difficulty in
writing a script to locates the files with a specific project ID. It
might be slightly slower than native find, but I don't think there is
any fundamental difference.
>
> The last time I asked why in the world anyone would want to use this
> feature, the only use case that I heard was people who were using
> containers, and where the all of the project id's were inside a
> chroot.  Hence, any questions I asked about what happens when a file
> gets moved out from the hierarchy were hand-waved away, since inside a
> chroot, it could never happen.
I think administrators in HPC or datacenter would like this feature in a
flexible way. I was always getting asked by customers 'how can I know
the spaces/inode used by directoris shared by multiple users/groups'.
'du' doesn't help much because no body wants to wait such a long time if
disk space is at PB-level. In this use case of project quota, I think
it is common for users to move files inside or outside directory-trees.

Regards,
                                       -Li Xi
--
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