On 9/7/05, Shailabh Nagar <[EMAIL PROTECTED]> wrote: > > 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'd think that the latter (a file shrinks/grows) is going to happen far more often and be more performance critical than adding/removing from a CKRM class, so wouldn't it be better to have the performance hit be during the class manipulation. 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
