Imposing storage quotas in a Unix filesystem is an interesting problem. It is interesting because there is an obvious approach that has been used quite successfully for twenty years or more, and which is wrong.
The obvious approach is to impose a quota for each user, and to charge the space used by each file to the user who owns the file, and then to prevent further allocations if the user's charged usage exceeds the user's quota. This works quite well quite often, but fails occasionally and so is imperfect.
One situation where it fails if when you have a group project that is being worked on by a number of members of a group. Files shared by a group could be owned by any member of the group, and the ownership could easily change as files are edited (if the editor creates a new file to replace an old one). In this case, one really wants a quota for the group, not for the members.
An apparently obvious solution is to allow quotas to be imposed on groups rather than users, and to charge file usage based on the group id of each file. This would solve the above problem, but creates others. Some people want to use group ownership purely for access control. In these cases it would not make sense for the group to have any quota as it isn't an entity that owns files so much as one that owns access rights.
Even here, it seems the we can work around the problem. We simply have some filesystems where the quota is based on group ownership, and some where the quota is based on user ownership. This can solve each problem, but introduces administrative complications. It is not always easy to know ahead of time what usage patterns are expected, and so whether to put certain files on a ``group'' filesystem or a ``user'' filesystem.
At UNSW/CSE we have tried all of these solutions and none of them are satisfactory.
On reflection we can see that there is something fundamentally inelegant about this whole approach. When faced with the possibility of imposing a quota on usage by individual users, one must face the question: Does the quota apply just on a single filesystem, or across all filesystems? When dealing with individual computers, it is possible to implement both alternatives, and at UNSW/CSE we have tried both, and each have their problems.
When dealing with a network of computers, having a single quota is impractical and so defining per-filesystem quotas is the norm. However neither answer is really good, and the problem seems to be that the question needs to be asked at all. A model for quotas that requires that sort of question to be asked seems to be fundamentally inelegant. It would be nice to have a model where that question simply didn't exist.
For the past year at UNSW/CSE we have been using a new model for quotas and all of the problems have simply disappeared. This new model is referred to a ``Tree quotas''. The idea is that usage of a file is charged to the 'tree' that it is in, and each tree has a quota. The ownership or group ownership of files within the tree is irrelevant. It is only the location in a particular tree that is important.
A 'tree', for the purposes of storage accounting, is considered to be any subtree of a filesystem, rooted at a directory not owned by root, and for which all ancestors in the filesystem are owned by root. Thus in a typical installation, every user's home directory would form an individual tree. This allows us to impose a quota on every home directory, and to not care about how the home directory is used, and what the ownership and group ownership of the files within that directory are.
We currently implement tree-quotas using a patch which makes use of a reserved-but-unused field in the ext2 and ext3 inode to store the tree-id of each file. This has proven very useful. However it seems unlikely that the maintainers of ext2 and ext3 will want to give up a field in the inode (a scarce resource) for treequotas.
So LaFS will have full integrated support for tree-quotas. This does not depend on the log-structuring of LaFS at all and could be implemented in any filesystem. However, except for our ext2/3 patches, it currently isn't, and we need it.