On Mon, Dec 23, 2013 at 10:12:19AM +0100, Arkadiusz MiÅkiewicz wrote:
> On Monday 23 of December 2013, Dave Chinner wrote:
> > > As always, any comment or idea are welcome.
> > I'd suggest that you implement project quotas, not directory quotas.
> > They are way more flexible than pure directory quotas, but with only
> > a few lines of code and a special directory flag they can be used to
> > > implement directory subtree quotas....
> Would be also nice to allow a file to belong to more than one project.
Not possible. Apart from there only being a single project ID to an
inode, having to account an inode ot mulitple project quotas
effectively makes every transaction in XFS have to modify an unbound
number of dquots. We don't have the infrastructure to do that, we
can't reserve log space for unbound sized transactions, etc.
> Let say I want to have
> /projects/ with 10GB quota
> /projects/projectA/ with 1GB quota
> /projects/projectB/ with 2GB quota
> and so on that's still limited by /projects/ 10GB quota limit.
What you get is exclusive accounting - the 10GB limit on /projects/
excludes the limits set on /projects/projectA/ and
Think about it for a minute - if we make subtrees nest like you
/projects/ with 10GB quota
/projects/projectA/ with 5GB quota
/projects/projectA/subproj1 with 3GB quota
/projects/projectA/subproj1/ssp2 with 2GB quota
/projects/projectA/subproj1/ssp2/sssp3 with 1GB quota
if we modify a file in ..../sssp3/, then we have 5 project quotas we
have to check for limit enforcement, reserve blocks on and then
transactionally modify (plus user and group for the file itself).
That's exceedingly complex because we don't have pointers to all
the inodes in the path back up to the root, so just to find that we
have nested project quotas requires a reverse path walk to find the
directory inodes to get their project IDs to look up the dquots we'd
need to modify. The complexity and performance overhead of recursive
project quota accounting simply isn't worth it.