On Mon, Jan 18, 2010 at 1:12 PM, Marc Aurele La France <[email protected]> wrote: > On Mon, 18 Jan 2010, Derrick Brashear wrote: >> >> On Mon, Jan 18, 2010 at 12:26 PM, Marc Aurele La France <[email protected]> >> wrote: >>> >>> On Sun, 17 Jan 2010, Simon Wilkinson wrote: >>>> >>>> On 17 Jan 2010, at 13:48, Marc Aurele La France wrote: >>>>> >>>>> Any chance of incorporating these into stable? > >>>> When we last discussed pullups for 1.4.12, we decided that these were >>>> too high risk for that release (the changes appeared very late in the >>>> release cycle). MS_NOATIME is sufficiently large that it doesn't appear >>>> to conflict with any inode flags, up to and including Linus's current >>>> kernel, so there doesn't appear to be a risk associated with not taking >>>> them this time round. > >>> Only one more inode flag is needed to create a conflict. Whether or not >>> this occurs before 1.4.13 is released is a risk I gather you are willing >>> to >>> take. I think it's better to be pro-active. > >> The question is "will it happen in a kernel 1.4.12 also doesn't >> support, making the issue somewhat less urgent?". > > Humm. That depends on whether or not a inode flag conflict is the only > reason it doesn't. Incompatible changes to kernel APIs have died down quite > a bit of late.
Things are indeed better lately, but I've yet to see a kernel that required no changes at all. I would also note that the latest inode flag (S_PRIVATE) is 5'ish years old, so this is not something that gets added very often. One worry for 1.4 is that setting MS_NOATIME may result in subtle changes in the VFS behaviour, which may change how/when our callback functions get called. In theory it shouldn't be an issue, but I guess the feeling was that it deserves more testing before landing in 1.4 at this stage of the release process. Marc _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
