On Wed, Oct 31, 2018 at 3:47 PM Vivek Goyal <vgoyal@xxxxxxxxxx> wrote: ... > > So "strict" will change behavior. That is where we think configuration > is not right/suboptimal, we will fail mount? > > I feel little odd about enabling "strict" implicitly just because > "metacopy" has been passed in. To me, for all new mount options, > "strict" should be default implementation (and does not require > strict to be on as such). > > For old options, users are already happy with what they are seeing > as of now. Those who want strict behavior, they should pass in > "strict=on" and then behavior of old knobs will change without > breaking backward compatibility. > We need to think of users and documentation and real life use cases. We need to think of overlayfs code maintenance and overlayfs developers. We need to come up with a compromise that is the best of all worlds. Maintaining different behavior per feature complicates the code and IMO brings no real value to users. If you think there is a concrete real world problem with metacopy=on implying strict=on, please present the case. Are you interested in making metacopy=on work on sub-optimal upper file systems? Which one? Are you interested in making index=on,metacopy=on fallback to index=off,metacopy=on on underlying fs without file handle support? Why? What is the real life use case for which you wish to preserve those behaviors that are mostly there because we made mistakes in the past? Thanks, Amir.
