Thoughts on Quotas

Samuel J. Greear sjg at evilcode.net
Tue Sep 28 11:56:15 PDT 2010


On Tue, Sep 28, 2010 at 12:01 PM, Nuno Antunes <nuno.antunes at gmail.com> wrote:
> On Tue, Sep 28, 2010 at 3:33 PM, Rumko <rumcic at gmail.com> wrote:
>> My 2 cents ...
>> With regards to having historical data included in the quota system. IMHO, it
>> should be included ...
>
> +1 to this approach too.
>
> On top of it, I'm not sure if this is feasible, but could there be a
> way to inform about the amount of space used by data *and* the amount
> of space used by historical data?
>
> Regards
> Nuno
>

Here's how I would see this working, if implemented this way. ...

There would be a quite plain VFS quota implementation as described on
the Summer of Code projects page, the only interesting bit is the
storage format would allow for optional extended information per-user.
Where the main store might have data like an array of uid's and
unsigned 64 bit bytes + gid's and unsigned 64 bit bytes. The extended
might be uid, bitmask specifying type (historical, acl, sparse, etc),
signed 64 bit bytes. The quota subsystem would have a public kernel
API which certain filesystems could opt into to provide additional
data on sizes. Any extended data would simply be additive to the
userland tools. You take base usage + history usage (if you have it,
and if you want) + (the negative) holes for a sparse file and you have
something resembling actual.

This would all take a bit of extra work, for sparse files we would
need something like SEEK_HOLE (Solaris?) so that the userland tools
which set up the initial quota files could determine the file hole
sizes + the filesystem would have to report the +/- change in sparse
area of a file relative to the +/- change in actual size the VFS layer
picked out (if any).

If I write VFS quota support (which is certainly possible as part of
GSoC 2011, but by no means guaranteed, someone please adopt this
project if you want it, I'll help) I would not include these extra's
as part of my proposal, but I could certainly leave room for them and
implement the public kernel API. Anyway, this seems workable to me and
would hardly affect the initial implementation.

Sam





More information about the Kernel mailing list