On 9/7/05, Shailabh Nagar <[EMAIL PROTECTED]> wrote: > > And when one specifies a share for <somegroup> it is the quota for all > member paths collectively ? >
That would be the idea, yes. (Most of the things I could see myself using it for would probably only have a single member path, but the principle of supporting multiple hierarchies shouldn't make things noticeably more complex). > 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. > > I've not looked at the existing quota code but it sounds like this > should be doable. I did something similar to this a few years ago that piggy-backed directly on the quota code. There were lots of nasty edge cases. > > 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) :-) I'm not sure - I'm tossing up between: - a CKRM extension - doing complicated group juggling in userspace to make it practical to use existing quotas for this and still be able to use group ACLs - using dnotify to let me know when files in a large directory have changes 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
