On Sat, Aug 09, 2014 at 06:17:10PM -0400, Theodore Ts'o wrote: > 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. Step into the enterprise or the HPC world where you are managing thousands of users spread across departmental/research groups and undertaking a few tens of distinct projects at the same time. Users have space limits, departments are billed for their user's space usage, and project space usage needs to be accounted (and maybe limited) to ensure the shared storage doesn't run out of space inapprpriately. 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. > 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. AFAICT, the 90% solution is "compatible with XFS" solution. It's also the simplest and lowest cost, given that you should be able to do it with a few hundred lines of kernel code. Userspace doesn't need immediate work, because you can use the XFS tools initially and hence all the xfstests validation. Don't be different just because of NIH syndrome.... 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... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
