Message-ID: <20140810221825.GN20518@dastard>
Date:	Mon, 11 Aug 2014 08:18:25 +1000
From:	Dave Chinner <david@...morbit.com>
To:	Theodore Ts'o <tytso@....edu>
Cc:	Li Xi <pkuelelixi@...il.com>, 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

On Sat, Aug 09, 2014 at 08:09:51PM -0400, Theodore Ts'o wrote:
> On Sun, Aug 10, 2014 at 09:38:32AM +1000, Dave Chinner wrote:
> > 
> > I've seen this sort of thing quite a bit over the past 10 years.
> > Most of the time on storage systems measured in the high tens to
> > hundreds of TB of storage, which puts it way out of the scope of
> > knowledge of most Linux distro and application developers. That's
> > most likely why you don't get any other answer to your questions -
> > most people can't see how project quotas get used because they've
> > never worked in a large, multi-project environment before.
> 
> Sure, but the people who are advocating for project quotas had better
> understand how they plan to use them, both so that (a) if they do a
> design different from XFS, they can justify why the differences are
> necessary, and (b) to justify whether we need it in ext4 to begin
> with.
> 
> The "directory hierarchy quota" is easy to understand, it's something
> that the Andrew File System had --- down to restriction that you can't
> move a file between different AFS volumes, but instead have to copy
> and unlink.

*nod* - that's the semantics the EXDEV error a cross-project rename
in the XFS rename code gives. Looking back at some of the comments
in the thread, I suspect that the behaviour this triggers in all
userspace utilities isn't clear: separately managed directory
hierarchies are designed to appear to userspace as separate
filesystems from an accounting and behavioural POV.

Note, also, that this means running df on a XFS filesystem with a
path inside a directory tree quota heirarchies will report the space
used of the direct tree quota, not the overall filesystem...

> > If we need a more *complex* solution because people need more than
> > just what the simple solution gives them, then that is a topic for
> > -fsdevel and probably LSFMM because there's all sorts of semantic
> > and interface discussions that are needed and a lot more code that
> > needs to be written. i.e. the simple solution can be deployed within
> > a couple of kernel releases, a generic solution is more likely a
> > coupleof *years* of work to deploy...
> 
> 100% agreed.  And I have yet to see a compelling case that even the
> simple form of project id's would get a lot of use in the ext4 world.
> Which is why I want to know from those who want to add project quotas
> in to ext4.  How do you plan to use them?  What's the use case
> scenario?

That's fair enough, though I think you'll find that the plain
project quota will find many different uses that filesystem
developers will have never thought of if it is there. e.g. I came
across an embedded NAS device a few years ago implemented with a
centralised object stores but had per-export space usage accounting
and enforcement by assigning every object associated with a specific
exported volume the same project quota....

Fundamentally, project quotas provide a quota mechanism that is
independent of both the filesystem heirarchy and the owner
credentials of the file. That means it can be used for all sorts of
things traditional u/g quotas cannot be used for and directory tree
quota is just one of them. As fs developers, we usually talk about
directory tree quota because it's the only project quota use case
that I've come across that needs kernel/fs help to implement sanely.
;)

Cheers,

Dave.
-- 
Dave Chinner
david@...morbit.com
--
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