On Wed, 2005-10-19 at 23:26 -0400, Shaya Potter wrote: > On Wed, 2005-10-19 at 20:50 -0400, Shaya Potter wrote: > > On Wed, 2005-10-19 at 15:52 -0400, Charles P. Wright wrote: > > > On Sun, 2005-10-16 at 03:27 -0400, Shaya Potter wrote: > > > > this is a first attempt at fixing up branching race conditions in > > > > unionfs, it's by no means complete. > > > > > > > > 1) It introduce a rw semaphore. The semantic is, that "write" is an > > > > operation that can change the branching structure. while "read" is > > > > operations that depend on the branching structure not changing. > > > > > > > > 2) I've removed the use of lock_super() in place of read/write locks as > > > > that would possibly kill performance due to being unable to run multiple > > > > branchput/gets at once and forcing a process to sleep. I haven't > > > > touched all the places that matter, just putting this out for > > > > discussion. > > > > > > > > my read_lock/unlock's around branchput in commonfops.c should probably > > > > be made much wider, but again this is just for proof of concept. > > > Shaya, > > > > > > Correct me if I'm wrong, but this basically looks like a performance > > > improvement more than a functionality fix. Have you actually seen > > > enough contention on the lock super to justify adding a distinct lock? > > > If so, do you have some numbers that demonstrate the difference? > > > > No. :) > > I should really expand on this remark. The reason I think it's better > to go with a read/write approach is that one really has to do a > lock_super() across very large swathes of code. > > for instance, code that does > > branchget > some works > > if (err) > branchput > > basically, none of the segments need to be used one at a time (atomic > operations enable that), but it seems like a waste too force them into > serialization and can seemingly hurt performance (if many many processes > accessing the union). I'll take a bite of the apple. I've committed your diff to the latest snapshot.
Charles _______________________________________________ unionfs mailing list unionfs@mail.fsl.cs.sunysb.edu http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
