From nobody Tue Jan 30 21:12:34 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TPdDL5rZcz57bsk for ; Tue, 30 Jan 2024 21:12:50 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TPdDL41XBz4qDn; Tue, 30 Jan 2024 21:12:50 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x1033.google.com with SMTP id 98e67ed59e1d1-290d59df3f0so3387795a91.2; Tue, 30 Jan 2024 13:12:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706649169; x=1707253969; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Ngm/KP76svoAzxeIeSltHMHDt3QrIZ/uMUqZgiCr8Ag=; b=ERtEqP9S2okZUNHvHsjtuFIpZUQnkjxscziEChGpRUo5LHg/aj+57omEPBmkXDzQNA eG2cLMx593/UEGut7LrT7HLcWmOnNOuds59HCCfmF6dyQN3vLpbVMKL2/BoYhdSuRqb6 y8DPDLf38bY0bBJont2PPKzKH7IVxCbOFfMSKTGoyTwCVsHSqG1z1lx0CqBYgLz3ZtI0 x/4EuZW93UbCPiEhEqF6a0HeXsvoZBUx63YY5mEU8mVgi3JW0xRyroiovam2kYSa/hwi ornWPrlcO19e2o6SXOCSM6ZsLBR1hMCsSd8ZKol9DXm8xhrRZaCi74I9l7FI4zeLCHWh Blkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706649169; x=1707253969; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Ngm/KP76svoAzxeIeSltHMHDt3QrIZ/uMUqZgiCr8Ag=; b=Em/g37FruKGQaeGPwAkkdT44UVAI9A1C9zzOA12XMKUnnEognBztYXea6hDcE7qrcH a0UXkKQvCgs4Yzw1f1zXyDOJBY8PJ44riCRqy1OPEDxbGvZsq6SAqWrqm3zIc6iqdWq2 NtCgYbfAlWZVzT+H4WuS7PHTp++m6KVCxBrncyuETE88GCFOaHS1w1wTiaQPnmKCPwdU ZBgo9226C/ERldtY+olKI7NiSHjso+IV3p953vBGFYA7+1lnPKZIzkw/gbRv8dDoqk5O 29svLXfZgIOD/psjZO6jNGYZVL6Pu4WPxNw/af66IdPGA0ec1OikTgnYu9sSBjTO8ZN9 w/hQ== X-Gm-Message-State: AOJu0YzwqwbvoOYvZE2Z81eXm5IfBRNMAlh+KO3k0wGszJgzLcAc//Wx vdMDUr+Bk0lR9fgDPg1im1Ay3EVFTmL6h71qYbOuqZTE26JkyhLxypLPbsAOmv7yDLiLOhfcVZM PoP7naE5/Gn8mCHKJ56GBJ/Tcpg== X-Google-Smtp-Source: AGHT+IHfX75Oeh1HQdAXPQGnyG2K+58XiF5RZ/KOp4Sx6ndtHRSqdN8rMBF1MsPlVUiM6flaKgpC8hiucvLbEo0wk7k= X-Received: by 2002:a17:90a:9f91:b0:290:1f0c:b742 with SMTP id o17-20020a17090a9f9100b002901f0cb742mr7050922pjp.28.1706649168448; Tue, 30 Jan 2024 13:12:48 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <3896441.telDhacX5M@ravel> <1732771.R3xgXyqmLP@ravel> In-Reply-To: From: Rick Macklem Date: Tue, 30 Jan 2024 13:12:34 -0800 Message-ID: Subject: Re: noatime on ufs2 To: Mike Karels Cc: Olivier Certner , Warner Losh , freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4TPdDL41XBz4qDn X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] On Tue, Jan 30, 2024 at 10:49=E2=80=AFAM Mike Karels wrot= e: > > On 30 Jan 2024, at 3:00, Olivier Certner wrote: > > > Hi Warner, > > > >> I strongly oppose this notion to control this from loader.conf. Root i= s > >> 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 tha= t 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, beca= use I only had a vague recollection of all this, and can confirm. > > > > I mentioned the need to modify '/etc/loader.conf' as a possible consequ= ence, not as a goal. Given what we have established, there is no need to c= hange 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 pr= operty due to the boot process design. > > With the possible exception that the sysctl mechanism might then have to > apply to mount update. > > >>>> It also seems undesirable to add a sysctl to control a value that th= e > >>>> kernel doesn't use. > >>> > >>> The kernel has to use it to guarantee some uniform behavior irrespect= ive > >>> 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 wi= th > >>> nmount(2), I would have to check (I seem to remember that, a long tim= e ago, > >>> when nmount(2) was introduced as an enhancement over mount(2), the st= ance > >>> 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. > > Based on a quick git grep, it looks like most of the things in base use > nmount(2), not mount(2). If they use mount(8), then it's not a problem > because mount(8) would be the first thing to get things right. If, by > mount helpers, you mean things like mount_nfs and mount_mfs, then mount(8= ) > uses them rather than the reverse. I also don't remember any admonition > not to use nmount(2). mount(8) has a limited set of file system types th= at > it handles directly. > > >> I disagree. I think Mike's suggestion was better and dealt with POLA a= nd > >> 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 publi= c 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? > > I don't think that stance has been taken; nmount(2) is certainly document= ed. > But I think that user level changes are required in both cases. First, f= or > the kernel to do the right thing, it needs to know if either noatime or a= time > has been specified explicitly, or if the default should apply. Otherwise= , the > kernel can only force noatime to be used in all cases or none, which I be= lieve > is a non-starter. Second, for anything using mount(2), the flags include= only > MNT_NOATIME, which can only include two options, not the required three. = It > would be possible to add another flag meaning to actually use the state o= f the > MNT_NOATIME flag, but that would require user-level changes. Third, if I > understand correctly, mount(8) parses the options and condenses the stand= ard > boolean options like {,no}atime into a bit, preserving the last option > specified. E.g. if the fstab lists noatime for a file system, and "mount= -o > atime ..." is given on the command line, noatime will not be included in > the kernel options. The kernel can't tell why, whether nothing was speci= fied > or the option was explicit. In theory, three states can be encoded using > nmount; options could include "atime", "noatime", or neither. But that's > not what the current user level does, so changes are required. Given tha= t, > it makes the most sense to have mount(8) and others to incorporate the > default into their operation, and just give the kernel the answer. btw, > see mntopts(3) for where this code would go. These days most mount options are parsed in the kernel via vfs_getopts(), but not "atime". It appears that "(no)atime" sets/clears MNT_NOATIME in userspace via the getmntopts() function that lives in /usr/src/sbin/mount/getmntopts.c. I think this is mostly cruft left over from the mount(2)->nmount(2) convers= ion, for generic options that cover all file systems. Personally, I like the idea of the addition of a defaults line in fstab(5), but am not sure what needs to be done for things like auto mounting? I'll admit I do not see what the default value of "(no)atime" is, so long a= s it can be overridden on a per mount basis. A change to what the installer sets= , seems fine to me. rick > > > Second, we can control what is in the base system, but not other applic= ations, 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 pr= ovide reliable behavior. My current evaluation is that changing userland w= ill require more code changes than the sysctl I propose, and it has all the= drawbacks I've just mentioned. > > I think that all of the user code needs changes in any case, for the reas= ons > above, so there is no need to change the kernel. > > > 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 fi= lesystems and already holds options to apply to particular mounts. But aga= in, this is independent of where the mechanism is actually implemented. > > Encoding the default as I proposed would make it awkward to communicate t= o > the kernel. A startup script that ran early enough could parse it and tu= rn > it into a sysctl, but the encoding works better for C programs that use > the fstab parsing code in mount(8). > > >> 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. > > I disagree, for the reasons above. > > > 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 pas= s them to the kernel (via 'vfs.root.mountfrom.options'), or the script remo= unting r/w be modified to apply the proper options (or 'mount -u' itself ch= anged to do so). > > The loader doesn't need the defaults. My proposal assumed that mount -u > would implement the default mechanism, just like mount without -u. > > >> If it's in fstab as default, then it would be read by whatever updates > >> things in user space. > > As described. > > > It's very unlikely that applications would not need modifications in th= is regard. Mike even said that he wouldn't have getfsent() return such ent= ries to avoid confusing existing programs. Needing specific code makes thi= s point moot (if you have to modify a program to read and process the speci= al lines in '/etc/fstab', you can as well modify it to use sysctl(8)). > > A sysctl would implement the default, but not per-filesystem options. > "mount -o atime /var/mail" should not be setting sysctls. > > > The real advantage is direct modifications in a text file by an adminis= trator, 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?). > > Again, I disagree that having the kernel involved is necessary or > desirable. > > >> 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 no= t at all atime focused: It could also be > >> generalized so that the FSTYPE could have different settings for diffe= rent 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. > > That's yet more mechanism that we don't need. > > >> I don't like this, because it is atime focused. atime is a trivial lit= tle > >> 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, t= here 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 bett= er because more in line with what we're doing for rc(8) and loader(8). Thi= s 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. > > The disadvantage of using /etc/defaults/fstab is that it hides the defaul= ts > in a file that didn't previously exist, so people won't know to look ther= e. > /etc/fstab is better in that it is most obvious. > > >> 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 def= aults must be implemented in the kernel. The inelegancy of the pure userla= nd 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). > > I disagree that the kernel can, or should, implement the change in defaul= ts > without modifying user level. External programs that use nmount(2) can't= do > the right thing *and* follow the defaults, because they don't tell the ke= rnel > how they arrived at the options they provide. > > >> It follows the 'tools not rules' philosophy the project has had for de= cades. > > > > FreeBSD is far from being the only project having it. Anyway, I've nev= er proposed anything not in these lines. Can you really argue that the sys= ctl proposal goes against that? > > > >> Anyway, I've said my piece. I agree with Mike that there's consensus f= or > >> this from the installer, and after that consensus falls away. Mike's i= dea > >> is one that I can get behind since it elegantly solves the general pro= blem. > > > > In the current situation, I can back using '/etc/fstab', or probably be= tter, '/usr/local/etc/fstab' to hold default mount options, but I'm strongl= y opposing a pure userland implementation as long as my objections above ar= e not addressed properly. > > We disagree. > > Mike > > > Thanks and regards. > > > > -- > > Olivier Certner >