Shailabh Nagar wrote:
Paul Menage wrote:
On 9/7/05, Shailabh Nagar <[EMAIL PROTECTED]> wrote:
Paul Menage wrote:
Hi,
Has anyone considered using CKRM to implement a "directory" classtype,
that would allow you to track/limit I/O and space usage for a set of
directory hierarchies?
Set of directory hierarchies in a regular (non-rcfs) filesystem ?
Yes.
The directory hierarchy in rcfs represent CKRM classes and don't have
any correspondence to disk filesystem hierarchies. So I don't see how
you'll specify the directory hierarchy you're trying to regulate (if
thats what you're suggesting).
I'd imagine it working something like:
echo $somepath > /rcfs/directory/somegroup/members
I see.
And when one specifies a share for <somegroup> it is the quota for all
member paths collectively ?
Yes, this does sound interesting alright and no one has explored
anything like this before.
and then $somepath and all files/directories below it would be
tracked. Probably done either by (ab)using the existing quota fields
in the inode, or adding a list field to link each inode in to the CKRM
class. There would probably need to be a restriction that no inode
could be hardlinked between multiple directory classes.
It might suffice to add a pointer to the CKRM class in the inode
structure (perhaps alongwith the quota fields), and during vfs_create,
check if the CKRM class' quota will be exceeded and deny accordingly.
Well, this isn't really a good idea since it'll involve adding/changing
inode fields for the entire hierarchy every time it is moved from one
members file to another.
Instead, at the time a directory is about to change in size, we can do a
path walk (upwards towards the mount point) and see if any of the inodes
along the way has a valid CKRM class assigned to it. If so, change its
"usage" of its quota appropriately and return with an error code that
determines if a size increase is allowed.
I've not looked at the existing quota code but it sounds like this
should be doable.
How useful would something like this be ? Not that it matters if you're
willing to code it up (but I'm sure you knew that already) :-)
It could be done with existing group quotas, with a separate groupid
created for each hierarchy, but that makes it trickier to use group
permissions on the directories in question.
Paul
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
ckrm-tech mailing list
https://lists.sourceforge.net/lists/listinfo/ckrm-tech
