On Wed, 2005-09-07 at 17:56 -0400, Shailabh Nagar wrote: > 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.
The first proposal slows down reclassification with simple field assignment. The second slows down truncate/append/create with a path walk. I think the truncate/append/create are the common cases and hence not having to walk a path during those operations would be ideal. Or maybe CKRM can tag along with a pre-existing walk?? Maybe a hybrid approach -- cache the class pointers and a generation number in the inodes. Class creation/removal would change the global generation number. If generation number has not changed then short circuit the path walk. Otherwise update the cache inside the path walk up to a matching generation number or the root. > > > > 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 > ------------------------------------------------------- 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
