Christoph Anton Mitterer posted on Tue, 15 Dec 2015 00:25:05 +0100 as excerpted:
> On Mon, 2015-12-14 at 22:30 +0100, Lionel Bouton wrote: > >> I use noatime and nodiratime > FYI: noatime implies nodiratime :-) Was going to post that myself. Is there some reason you: a) use nodiratime when noatime is already enabled, despite the fact that the latter already includes the former, or b) didn't sufficiently research the option (at least the current mount manpage documents that noatime includes nodiratime under both the noatime and nodiratime options, and at least some hint of that has been in the manpage for years as I recall reading it when I first read of nodiratime and checked whether my noatime options included it) before standardizing on it, or c) might have actually been talking in general, and there's some mounts you don't actually choose to make noatime, but still want nodiratime, or d) chose that isn't otherwise reflected in the above? If so, please describe, as it could be a learning experience for me, and possibly others as well. >> Finally Linus Torvalds has been quite vocal and consistent on the >> general subject of the kernel not breaking user-space APIs no matter >> what so I wouldn't have much hope for default kernel mount options >> changes... > He surely is right in general,... but when the point has been reached, > where only a minority actually requires the feature... and the minority > actually starts to suffer from that... it may change. Generally speaking, the practical rule is that you don't break userspace, but that a break that isn't noticed and reported by someone within a few release cycles is considered OK, as obviously nobody who actually cares enough about the possibility of old userspace breaking on new kernels enough to test for it was (still) using that functionality anyway. (This is sometimes known as the "if a tree falls in the forest and there's nobody around to hear it, did it actually fall", rule. =:^) But if it's noticed and reported before the new behavior itself is locked into place by other userspace relying on it, the change in behavior must be reverted. (There have actually been a few cases over the years where they went to rather exceptional lengths to make two otherwise incompatible userspace-exposed behaviors both continue to work for the userspace that expected that behavior, without actually coding in such obvious hacks as executable name conditionals or the like, as others have been known to do at times. Sometimes these fixes do end up bending the rules a bit, particularly the no-policy-in-the-kernel rule, but they do reinforce the now userspace breakage rule.) The possible workarounds include the handful of kernel compatibility options that when enabled continue otherwise userspace breaking behavior such as removing old kernel API procfs files and the like. That practical rule does in effect make it possible to do userspace- breaking changes if you wait around long enough that there's nobody who will complain still actually using the old behavior. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
