gluster-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gluster-devel] Re: QUOTA xlator (redesigned unlink accounting fops)


From: Anand Avati
Subject: [Gluster-devel] Re: QUOTA xlator (redesigned unlink accounting fops)
Date: Tue, 22 Jan 2008 01:35:51 +0530

Angel,
 your idea about pipelining two calls are correct. But i suggested doing a
statfs _after_ unlink (only if it was successful) so that you just use the
new statfs buf returned by it, without worrying about hardlinks or stuff.
You could do this with rmdir, truncate etc and not duplicate the
'calculation' which storage/posix already does, and more accurately as well.

avati

2008/1/21, Angel <address@hidden>:
>
> 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 <address@hidden>:
> > >
>
> --
> ------------------------------------------------
> Clist UAH
> ------------------------------------------------
>



-- 
If I traveled to the end of the rainbow
As Dame Fortune did intend,
Murphy would be there to tell me
The pot's at the other end.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]