Re: Thoughts on Quotas

["Samuel J. Greear" <sjg@xxxxxxxxxxxx>]

On Tue, Sep 28, 2010 at 12:01 PM, Nuno Antunes <nuno.antunes@gmail.com> wrote:
> On Tue, Sep 28, 2010 at 3:33 PM, Rumko <rumcic@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