On Tue, 21 May 2013 10:30:46 -0400 Jeff Darcy <jdarcy@xxxxxxxxxx> wrote: > On 05/21/2013 10:10 AM, Stephan von Krawczynski wrote: > > See it as a corner case of a configurable option like: > > > > self-heal-chunksize = X > > 128k < X < (unsigned)-1 (meaning all bits 1, don't know how many you have > > here :-) > > Unfortunately that doesn't quite work because a whole-file lock covers more > than just the data bits - i.e. inode information including size. Really it's > more like there are two locks, but the second (inode) is always taken > concurrently with the first (data). Maybe what we need to do is actually treat > it as two locks, similar to the approach Pranith suggested but where truncate > also interacts with the non-data lock. This approach would also be more > consistent with the data/metadata distinction we make for a changelog, reducing > the number of permutations we have to consider. My suggestion was thought as a user-configurable switch and corresponding values. I didn't mean it as implementation proposal. Of course the real implementation should deal with caveats not transparent to configuration or the user per se. -- Regards, Stephan
