Yes, any time behavior is changed, either to fix a bug or introduce a new feature, there is the possibility that someone somewhere might have been relying on the previous behavior. But you can't introduce backwards compatible settings for each and every change ever made, that would just be unwieldy and poor design.
In this case, the change is restoring proper behavior for a documented interface that was temporarily doing the wrong thing. Particularly given as of yet there haven't been any concrete examples as to how this might be desirable behavior, this doesn't seem like a scenario where such a kludge would be appropriate. I take it you work for RackTop? Why is it you think your customers would want to continue with the broken behavior rather than the correct behavior for this aclinherit setting? Further, as I suggested, if this behavior is desirable for someone, it would be better implemented as a separate aclinherit option rather than providing the confusing ability to have an existing documented mode behave differently. The current broken behavior wouldn't be the default, so an admin reading the release notes would have to do something to maintain it, whether it be setting a kernel tunable or changing an aclinherit setting. Plus a new setting would allow it to be set on a per filesystem basis rather than globally; what if you have some customers who want the fixed behavior and others who want the "different in general but broken for this setting" behavior? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/openzfs/openzfs/pull/557#issuecomment-367145972 ------------------------------------------ openzfs-developer Archives: https://openzfs.topicbox.com/groups/developer/discussions/Taa24d3ad3ace2410-M5fdc823746043a62f3518ab9 Powered by Topicbox: https://topicbox.com
