Oh!! avati im sorry again
i write and write and never read enough what ive written!!
whenever i wrote statfs i was meaning "stat" because i wanted to "stat"
the file to see how many hardlinks has and whats its size and because im
assuming other process in server can access underlaying filesystem where
posix-volumes reside thus modifying statfs data unexpectely so i cant account
for statfs as i dont know if values changes accordingly to fops on glusterfs or
tasks running on the server.
You unliked one file and stafs showed 3GB freed,
It was you? or
it was server sysadmin deleting also older iptables logs?
Better to see how much size and how many links before deleting to account properly
Do yoy agre in that?
thus i need to stat file prior being deleted,
Iill wait your comments on this, in the mean time ill change implementation of serials call to the new dual fire!!
Regards
Angel
El Lunes, 21 de Enero de 2008 Anand Avati escribió:
> 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 <clist@xxxxxx>:
> >
> > 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@xxxxxx>:
> > > >
> >
> > --
> > ------------------------------------------------
> > Clist UAH
> > ------------------------------------------------
> >
>
>
>
--
------------------------------------------------
Clist UAH
------------------------------------------------
