[Gluster-devel] QUOTA xlator (redesigned unlink accounting fops)
Angel
clist at uah.es
Mon Jan 21 13:38:07 UTC 2008
Avati
thanks for helping me
I still dont get all the picture but im trying...
firing two calls in one pass? I dont get it...
(several beers later...)
lets try
1- I get called on quota_unlink (someone wants to unlink a file)
quota_unlink(...)
struct stat *mybuf=calloc(...) // I calloc a private stat * mybuf
point frame->local to mybuf // is that correct mybuf is owned now by me not posix-storage ahh??
well lets dual fire downwards
// WIND or UNWIND?? I never remember (my English need maintenance...)
STACK_WIND "statfs (statfs_cbk, unlink_requested_file)" // Its just pseudocode!!
STACK_WIND "unlink(unlink_cbk, unlink_requested_file)"
return;
"They are exec in order so..."
2- I get called first on quota_statfs_cbk
quota_statfs_cbk(...)
if (frame->local is NULL) // do normal callback unwinding..
{
procced to upper xlator stack unwinds..
} else { // im using statfs for private affairs...
mybuf = frame->local // recover mybuf , hey you this is mine!!
frame->local= NULL // dont trash thigs
memcopy stat buf returned to mybuf
mybuf = memcpy(buf) // later unlink_cbk will need this
no one but me expected this callback, dont unwind stack call
}
return,
Later...
3- quota_unlink_cbk(...)
// Ok! the file was deleted??
//frame->local gives me a gift
mybuf = frame->local // recover stat mybuf
frame->local = NULL // sanitize
if ( mybuf->hardlinks >= 1) { // Ok, Ok file was hardlinked, better luck next time
do_nothig_on_quotas_at_all();
} else { // Hey whats this? file was not linked!! we recovered storage
do_quota_subs(buf->st_size);
}
free (mybuf) // thats all folks!! see you next unlik...
STACK_UNWINDS(...) // go, go with your mamma
}
return
NOW THE QUESTION!!
Its thats ok? i got the idea?
Regards
Angel
El Lunes, 21 de Enero de 2008 Anand Avati escribió:
> Angel,
> Thanks for kickstarting :) Some comments -
>
> 1. Storing stat from pre_unlink_stat_cbk into frame->local is not right
> since.
>
> 2. Instead of having a pre_unlink_stat and then subtracting (after fixing
> the storage of stat), why not have a post_unlink_statfs() ? That sounds a
> lot neater implementation. It also guards against hardlinks getting wrongly
> calculated twice. You can also improve the performance by pipelining unlink
> and statfs one after another without waiting for the callback from the other
> (the order of two stack_winds from the same thread will guarantee the same
> order of execution at posix (if they both are headed towards the same
> storage/posix) unless the calls are a mix of file/non-file (in this case
> both are non-file, so order is guaranteed).
>
> 3. it would also be convinient if you 'unimplement' the remaining fops which
> are copied from trace.
>
> 4. do you have any thoughts on per-user or per-dir? If so I would like to
> discuss as we are discussing internally with a few algos for doing the most
> efficient per-dir quota.
>
> thanks,
> avati
>
> 2008/1/20, Angel <clist at uah.es>:
> >
--
------------------------------------------------
Clist UAH
------------------------------------------------
More information about the Gluster-devel
mailing list