Re: Thoughts on Quotas
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
討論串 (同標題文章)
完整討論串 (本文為第 21 之 32 篇)：