QUOTA xlator (redesigned unlink accounting fops)

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

 



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
------------------------------------------------




[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux