Hi Warner, > I strongly oppose this notion to control this from loader.conf. Root is > mounted read-only, so it doesn't matter. That's why I liked Mike's > suggestion: root isn't special.
Then in fact there is nothing to oppose. You've just said yourself that root is mounted first read-only. As Mike already said, it is remounted r/w in userland later in the boot process. I just re-checked the code, because I only had a vague recollection of all this, and can confirm. I mentioned the need to modify '/etc/loader.conf' as a possible consequence, not as a goal. Given what we have established, there is no need to change it at all. The root FS is thus in no way more special in the sysctl proposal than with Mike's (assuming it doesn't rely on sysctl), this is an independent property due to the boot process design. > > > It also seems undesirable to add a sysctl to control a value that the > > > kernel doesn't use. > > > > The kernel has to use it to guarantee some uniform behavior irrespective > > of the mount being performed through mount(8) or by a direct call to > > nmount(2). I think this consistency is important. Perhaps all > > auto-mounters and mount helpers always run mount(8) and never deal with > > nmount(2), I would have to check (I seem to remember that, a long time ago, > > when nmount(2) was introduced as an enhancement over mount(2), the stance > > was that applications should use mount(8) and not nmount(2) directly). > > Even if there were no obvious callers of nmount(2), I would be a bit > > uncomfortable with this discrepancy in behavior. > > > > I disagree. I think Mike's suggestion was better and dealt with POLA and > POLA breaking in a sane way. If the default is applied universally in user > space, then we need not change the kernel at all. I think applying the changes to userland only is really a bad idea. I've already explained why, but going to do it again in case you missed that. If you have counter-arguments, fine, but I would like to see them. Changing userland only causes a discrepancy between mount(8) and nmount(2). Even if the project would take a stance that nmount(2) is not a public API and mount(8) must always be used, the system call will still be there. And if it's not supposed to be used, what's the problem with changing it as well? Second, we can control what is in the base system, but not other applications, so we can't really prevent nmount(2) to be used. Some of the goals of my proposal include to simplifying things, both in terms of administration but also in terms of the amount of code, and to provide reliable behavior. My current evaluation is that changing userland will require more code changes than the sysctl I propose, and it has all the drawbacks I've just mentioned. What I find great in Mike's proposal is to use '/etc/fstab' to control filesystem defaults, because '/etc/fstab' is already the go-to place for filesystems and already holds options to apply to particular mounts. But again, this is independent of where the mechanism is actually implemented. > We lose all the chicken and egg problems and the non-linearness of the sysctl > idea. As already said above, there is in the end no such problem, and it wasn't linked at all with the sysctl idea. On the contrary, with the '/etc/fstab' proposal, if there is no kernel backing, the loader must be modified to parse default options, and then pass them to the kernel (via 'vfs.root.mountfrom.options'), or the script remounting r/w be modified to apply the proper options (or 'mount -u' itself changed to do so). > If it's in fstab as default, then it would be read by whatever updates > things in user space. It's very unlikely that applications would not need modifications in this regard. Mike even said that he wouldn't have getfsent() return such entries to avoid confusing existing programs. Needing specific code makes this point moot (if you have to modify a program to read and process the special lines in '/etc/fstab', you can as well modify it to use sysctl(8)). The real advantage is direct modifications in a text file by an administrator, and this is why I like the '/etc/fstab' idea. > It obviates the need for the sysctl entirely. It doesn't obviate the need for a kernel mechanism (sysctl(8) or else), see argument on mount(8) and nmount(2) above. And once you need a kernel mechanism, sysctl(8) is most probably the best candidate for tunables (why re-invent the wheel?). > It gets around the need to update loader.conf as well. You keep repeating that, but it's false as explained above. > It concentrates the change in one place and does so in a way that's not at > all atime focused: It could also be > generalized so that the FSTYPE could have different settings for different > types of filesystem (maybe unique flags that some file systems don't > understand). You can also have this with a properly designed sysctl(8) hierarchy. > I don't like this, because it is atime focused. atime is a trivial little > optimization that really isn't worth the effort for the vast majority of > things. Others have disagreed, not going to summarize all the previous mails, there are for anyone to read. > However, it would be nice to have some way to specify another layer > of defaults, like we do for rc variables, loader variables, etc. mount is > currently missing that generality. One could also put it in > /etc/defaults/fstab too and not break POLA since that's the pattern we use > elsewhere. I also think having the defaults in '/etc/defaults/fstab' would be better because more in line with what we're doing for rc(8) and loader(8). This would be at the expense of discoverability for adopters, but it seems to be worth it given it applies to other things and has some logic. > I don't think the case for sysctl has been made. It's a big, inelegant > hammer that can be solved more elegantly like Mike suggested. I think it's the exact opposite. As explained above, the change in defaults must be implemented in the kernel. The inelegancy of the pure userland solution will become apparent in terms of the necessary changes' content, its higher number of lines of code and its intrinsic unreliability in the face of external applications using nmount(2). > It follows the 'tools not rules' philosophy the project has had for decades. FreeBSD is far from being the only project having it. Anyway, I've never proposed anything not in these lines. Can you really argue that the sysctl proposal goes against that? > Anyway, I've said my piece. I agree with Mike that there's consensus for > this from the installer, and after that consensus falls away. Mike's idea > is one that I can get behind since it elegantly solves the general problem. In the current situation, I can back using '/etc/fstab', or probably better, '/usr/local/etc/fstab' to hold default mount options, but I'm strongly opposing a pure userland implementation as long as my objections above are not addressed properly. Thanks and regards. -- Olivier Certner
signature.asc
Description: This is a digitally signed message part.
