On Tue, Sep 28, 2010 at 12:01 PM, Nuno Antunes <[email protected]> wrote: > On Tue, Sep 28, 2010 at 3:33 PM, Rumko <[email protected]> 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
