Hi i know, statfs is what i did, the names weren descriptive, you can check it on the patch i send. previously i was thinking stat mops provided required values... i also plan to do statfs on ftruncate but using a generalized statfs_cbk (for unlink and for ftruncate). and oher functions passing on frame->local a struct containing values across call and pointer to apropiate final function_cbk so my pre_unlink_stat_cbk get generalized and avoid code duplication. Also added quota_add , quota_check, quota_sub to manipulate quota values added to struct quota_private Im also cleaning code from trace and studing trash to learn how to originate a bunch of calls to a statfs from init to get current volume usage on startup, i would prefer to have such function on posix-storage but nobody is perfect :-P Regards, El Lunes, 21 de Enero de 2008 Anand Avati escribió: > Comments inline. > > > > - notify works, future plannings on doing "du -chs" like ops on init for > > accounting previous run files. > > > > - statfs return correct values forcing scheduler's to choose other nodes > > on quota hit > > > > - I can account for data blocks write ops on write_cbk ops. > > > > On unlink my plan is: > > place a call to stat for calculating file size, place > > pre_unlink_stat_cbk for return > > on pre_unlink_stat_cbk copy buf->st_size on a calloc'ed > > *int32_t and place it on frame ->local > > and then put a call to unlink downwards for delete file, > > place unlink_cbk for return > > on successfull unlink_cbk will account for freed bytes > > (frame->local) and return (unwind) for parent. > > > why not do a fresh statfs() instead of a stat() ? I am assuming this is for > limiting overall size and not per-user or per-directory. > > avati > -- ------------------------------------------------ Clist UAH ------------------------------------------------
