White paper: Vendor Kernels, Bugs and Stability

Posted May 17, 2024 14:28 UTC (Fri) by willy (subscriber, #9762)
In reply to: White paper: Vendor Kernels, Bugs and Stability by bluca
Parent article: White paper: Vendor Kernels, Bugs and Stability

I don't understand why they felt the need to remove these mount options. I made NFS "intr" a no-op in 2007 and have no intention of ever removing it. Just laughing smugly to myself every time I see a new article written that extols the benefits of using "intr" as a mount option.

White paper: Vendor Kernels, Bugs and Stability

Posted May 17, 2024 14:55 UTC (Fri) by bluca (subscriber, #118303) [Link] (4 responses)

That sounds indeed like the appropriate way to do these kind of changes - an option is not needed anymore? Make it a no-op, maybe log a message, but just leave it there, so nothing is broken.

I mean we change public interfaces like this in systemd too every now and then - but we just keep the old configuration option around too, undocumented, and either map it to the new one if any, or make it a no-op.

White paper: Vendor Kernels, Bugs and Stability

Posted May 17, 2024 15:06 UTC (Fri) by mb (subscriber, #50428) [Link] (3 responses)

Making things a no-op also is an interface change. You're just hiding the fact.

White paper: Vendor Kernels, Bugs and Stability

Posted May 17, 2024 15:17 UTC (Fri) by bluca (subscriber, #118303) [Link] (2 responses)

It is, the point is that if an interface change is needed, then it's better to make it transparent than to hard break stuff, in case it's something that it's no longer necessary and doesn't make any difference anyway.

White paper: Vendor Kernels, Bugs and Stability

Posted May 17, 2024 16:14 UTC (Fri) by mb (subscriber, #50428) [Link] (1 responses)

>then it's better to make it transparent than to hard break stuff

No. It depends on the change itself whether a silent ignore is better or not. It might be worse to silently ignore something the user has requested.

White paper: Vendor Kernels, Bugs and Stability

Posted May 17, 2024 16:22 UTC (Fri) by bluca (subscriber, #118303) [Link]

> in case it's something that it's no longer necessary and doesn't make any difference anyway.

White paper: Vendor Kernels, Bugs and Stability

Posted May 17, 2024 16:20 UTC (Fri) by joib (subscriber, #8541) [Link] (6 responses)

Ha ha. At a $PREVIOUS_JOB I removed intr from our mount options precisely because it was a no-op by then. Lo and behold, a few months later someone else helpfully added them back "in order to make NFS more robust against hangs that otherwise would require a reboot". ;-)

White paper: Vendor Kernels, Bugs and Stability

Posted May 17, 2024 16:53 UTC (Fri) by adobriyan (subscriber, #30858) [Link] (5 responses)

In theory, kernel could do equivalent of "sed -i '/intr//g' /etc/fstab via call_usermodehelper()...

White paper: Vendor Kernels, Bugs and Stability

Posted May 18, 2024 19:46 UTC (Sat) by NYKevin (subscriber, #129325) [Link] (4 responses)

There are a couple of problems with this idea:

0. /etc/fstab is a configuration file. It's not the kernel's place to modify config files (software like Puppet or Ansible will change it back).
1. Assuming you meant /etc/mtab, that's (usually) managed in userspace. It's also none of the kernel's business.
2. Assuming you meant /proc/mounts, there might be some userspace software that parses it and compares it against what it "should" look like, and misbehaves if a random mount option is missing (e.g. gets stuck in a hot loop of repeatedly remounting the device with the "correct" mount options, fires an alert and tells the sysadmin to come running, etc.).

(No, paging the sysadmin at 3 AM is not a reasonable response to this situation. Nothing is actually broken!)

White paper: Vendor Kernels, Bugs and Stability

Posted May 18, 2024 20:29 UTC (Sat) by adobriyan (subscriber, #30858) [Link] (1 responses)

> It's not the kernel's place to modify config files

I know, relax :-) it was a joke.

White paper: Vendor Kernels, Bugs and Stability

Posted May 19, 2024 4:01 UTC (Sun) by wtarreau (subscriber, #51152) [Link]

Even as a joke, please do not throw ideas like this, there's always a risk someone finds them great and starts to try to implement them and advocate them around.

White paper: Vendor Kernels, Bugs and Stability

Posted May 19, 2024 9:07 UTC (Sun) by smurf (subscriber, #17840) [Link] (1 responses)

Umm, /etc/mtab isn't managed in userspace. Or rather, it hasn't been for ages. These days it's a symlink to /proc/self/mounts.

White paper: Vendor Kernels, Bugs and Stability

Posted May 20, 2024 17:35 UTC (Mon) by NYKevin (subscriber, #129325) [Link]

It was... like 10-15 years ago when I cut my teeth on this stuff. But nowadays, we have software for everything, so I haven't actually played with low-level mounting etc. in a long time.

Which is also, sort of, the point I'm trying to make here. It is no longer accurate to divide userspace into "applications" and "stuff the sysadmin manually fiddles with." Sysadmins are not manually fiddling with mount options etc. these days. That's all managed by some other piece of software that isn't "the application," but can still break and cause problems all the same. E.g. k8s, Puppet, Docker, etc.

White paper: Vendor Kernels, Bugs and Stability

Posted May 18, 2024 17:11 UTC (Sat) by shemminger (subscriber, #5739) [Link]

There are various networking statistics in /proc that have been always 0 since 2.4 kernel days since the code changed and those statistics were no longer relevant.
Easier to just silently sweep legacy under the rug, and get on with fixing real issues.

White paper: Vendor Kernels, Bugs and Stability

Posted May 19, 2024 4:00 UTC (Sun) by wtarreau (subscriber, #51152) [Link]

I still have it on commented out lines in my fstab ;-)