On Tue, 21 May 2013 09:10:18 -0400 (EDT) Pranith Kumar Karampuri <pkara...@redhat.com> wrote:
> [...] > Solution: > Since we want to prevent two parallel self-heals. We let them compete in a > separate "domain". Lets call the domain on which the locks have been taken on > in previous approach as "data-domain". > > In the new approach When a self-heal is triggered it > acquires a full lock in the new domain "self-heal-domain". > After this it performs data-self-heal using the locks in "data-domain" in > the following manner: > Acquire full file lock and get xattrs on file and decide source/sinks > unlock full file lock. > acquire lock with range 0 - 128k, sync the data from source to sinks in > range 0 - 128k unlock 0 - 128k lock. > acquire lock with range 128k+1 - 256k, sync the data from source to sinks > in range 128k+1 - 256k, unlock 128k+1 - 256k lock. > ..... > until the end of file is reached do this. > acquire full file lock and decrement the pending counts then unlock the > full file lock. > unlock the full file lock in "self-heal-domain" > > scenario-1 won't happen because there exists a chance for it to acquire > truncate's full file lock after any 128k range sync happens. > Scenario-2 won't happen because extra self-heals that are launched on the > same file will be blocked in self-heal-domain so the data-path's locks are > not affected by this. > > Let me know if you see any problems/suggestions with this approach. > > Pranith. I am not quite sure if I understood the issue in full detail. But are you saying that you "split up" the current self-healing file in 128K chunks with locking/unlocking (over the network)? It sounds a bit like the locking takes more (cpu) time than the self-healing of the data itself. I mean this can be a 10 G link where a complete file could be healed in almost no time, even if the file is quite big. Sure WAN is different, but I really would like to have at least an option to drop the partial locking completely and lock the full file instead. -- Regards, Stephan _______________________________________________ Gluster-devel mailing list Gluster-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/gluster-devel
