On Sun, Nov 09, 2014 at 01:43:37AM +0800, Li Xi wrote:
This patch adds a new internal field of ext4 inode to save project
identifier. Also a new flag EXT4_INODE_PROJINHERIT is added for
inheriting project ID from parent directory.
What would be the downside of simply always inhereiting the project ID
from the parent directory? I see that if the flag is not set, the
project id will be 0 instead. I'm not sure when that would actually
be desirable.
To the extent that the project ID is designed to implement a quota
over a directory extent, the fact that the owner can clear the
EXT4_PROJINHERET_FL and then arrange to have the quota charged to
project 0 seems to me to be a bug, not a feature.
Can you explain what your intended use case for this flag might be?
Thanks,
- Ted
On Tue, Nov 11, 2014 at 12:26 PM, Theodore Ts'o [off-list ref] wrote:
On Sun, Nov 09, 2014 at 01:43:37AM +0800, Li Xi wrote:
quoted
This patch adds a new internal field of ext4 inode to save project
identifier. Also a new flag EXT4_INODE_PROJINHERIT is added for
inheriting project ID from parent directory.
What would be the downside of simply always inhereiting the project ID
from the parent directory? I see that if the flag is not set, the
project id will be 0 instead. I'm not sure when that would actually
be desirable.
To the extent that the project ID is designed to implement a quota
over a directory extent, the fact that the owner can clear the
EXT4_PROJINHERET_FL and then arrange to have the quota charged to
project 0 seems to me to be a bug, not a feature.
Yeah, if we only intend to implement quota over directories, always inheriting
project ID from parent directory is fine. But we want this to be more flexible,
thus more powerful to enable other use cases. Always inheriting project ID
from parent means inodes uner the same subtree has the same project ID,
which might limit some use cases.
For example, if the administrator wants to track the disk usages of files
which scatter under different directories yet has similar attributes (e.g.
the sizes of them are really big), they can use project quota to archive
this goal. Combining 'find' command with setting project ID is really
convenient for this use case. And obviously, it wounldn't be possible,
if we don't have a mutable EXT4_INODE_PROJINHERIT flag.
Please note that project ID can only be change by administrator,
which means even the owners of the files can't change the project IDs.
The idea behinds it is that project quota is a tool for administrators, not
for common users.
And EXT4_INODE_PROJINHERIT is introduced into Ext4 in oder to keep
compatibile with XFS too. Otherwise, they would have different semantics. ;)
Regards,
- Li Xi
On Mon 10-11-14 23:26:06, Ted Tso wrote:
On Sun, Nov 09, 2014 at 01:43:37AM +0800, Li Xi wrote:
quoted
This patch adds a new internal field of ext4 inode to save project
identifier. Also a new flag EXT4_INODE_PROJINHERIT is added for
inheriting project ID from parent directory.
What would be the downside of simply always inhereiting the project ID
from the parent directory? I see that if the flag is not set, the
project id will be 0 instead. I'm not sure when that would actually
be desirable.
Well, 0 is a fallback project ID effectively meaning "not accounted in
project quota".
To the extent that the project ID is designed to implement a quota
over a directory extent, the fact that the owner can clear the
EXT4_PROJINHERET_FL and then arrange to have the quota charged to
project 0 seems to me to be a bug, not a feature.
Can you explain what your intended use case for this flag might be?
So I agree that for directory quotas there's no reason not to inherit the
project ID. But there might be other use cases and I strongly prefer to
stay compatible with XFS as far as reasonably possible to make life for
userspace simpler.
Honza
--
Jan Kara [off-list ref]
SUSE Labs, CR