On 7/26/18 4:17 PM, Dave Chinner wrote: ... > As it is, I don't think we can remove this now - people are using > the on-disk flags already, and the inherit flag from the directory > has none of the problems of changing S_DAX dynamically. Which is why I left the inheritance part ... > Hence just > disabling it is the wrong thing to do because it removes the ability > for people to manage the flags that are already on disk.... Well, it's EXPERIMENTAL... o_O But yeah, this does remove the ability to turn off the flag, at least w/o making a file copy or some other gross thing. > I'd much prefer we fix the page fault synchronisation problem than > break stuff that /isn't actually broken/. Yes, it's current > behaviour is suboptimal, but that is only supposed to be /temporary/ > until the aops callout problem is fixed. Well, it's super confusing and from the user POV more or less nondeterministic, at this point. That borders on broken/unusable IMHO. "Change the flag and some time later, not really within your control, the behavior will change." It's been broken for a year. TBH I'm not sure I personally have the knowledge/skill (and I almost certainly don't have the time) to fix it. Just trying to make the best of a sticky situation. This seemed better to me, modulo the inability to remove the flag. :/ And I figured more permissive flag manipulation could be added back later if it ever does get fixed. Thanks, -Eric > Cheers, > > Dave. > -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
