On Fri, Jan 12, 2007 at 11:28:21AM -0500, Shaya Potter wrote:
> Here's my optimization patch (quick and dirty, looks bigger than it is, 
> most of it is changing indenting of already existing code within if() 
> statements I added)  w/ postmark numbers.  I'm a little confused as now 
> unionfs on backing store is faster than plain backing store (albiet not 
> many test iterations and my methodology might be suspect, any thoughts?)
> 
> so what do I do.
> 
> 1) anywhere we check for a whiteout (lookup.c or inode.c), we don't 
> check for it if the bindex we are searching in is bend/bopaque as, a 
> whiteout shouldn't exist there.

The way you worded that it almost sounds like we are altering the semantics
a bit. It is more of a reduction, much like:

if (1 || foo) {} 

will always be true.

> for lookup.c ( unionfs_lookup_backend() ) that is the major loop and 
> basically skip whiteout search if bindex = bend
> 
> for inode.c, since we are only looking in bstart for the whiteout, its 
> if bstart = bend (or opaque if < bend and != -1)
> 
> there's also some whiteout code in rename.c that I didn't get to yet 
> (though probably have to).

Ok.

> I also addressed whiteout code in unlink.c, unionfs_unlink_whiteout() 
> always created a whiteout, even in a case where there was nothing to 
> whiteout.  In those cases (I believe, didn't change any branching just 
> changed a create_whiteout() to "goto out").
 
Makes sense.
 
> similarly for rmdir, one shouldn't create a whiteout if one doesn't have to.

Yep.

> and this is what I mean by having to change rename as it also probably 
> creates whiteouts when it doesn't have to.

Ok.

> as can be seen from the attached pdf, the speedup in postmark is 
> remarkable, though makes perfect sense.  Also attaching the raw 1 run 
> numbers

Very odd that the optimized case is faster than the base fs.

Thanks for the patch!

Josef "Jeff" Sipek.

-- 
The box said "Windows XP or better required". So I installed Linux.
_______________________________________________
unionfs mailing list
[email protected]
http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs

Reply via email to