Re: noatime on ufs2
> 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. Typo, '/usr/local/etc/fstab' should read '/etc/defaults/fstab'. -- Olivier Certner signature.asc Description: This is a digitally signed message part.
Re: noatime on ufs2
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.
Re: noatime on ufs2
b'. > btw, I think there is consensus that noatime is the most useful setting for > most systems and users. However, I don't think there is consensus that the > default should be changed for things like mount with no options. I think > that putting a default somewhere fairly obvious could make it more palatable > (less POLA violation). Opinions may vary, though. To be clear, when you say mounting without options, there are two cases with mount(8): - Either a single argument referencing some line in '/etc/fstab', which could well specify an explicit 'noatime' or 'atime', in which case of course it should apply, not the global default. If the fstab line doesn't specify either one, should the global default apply? For consistency and simplicity, I think it should. - A device and a mount point, in which case I don't see why the default shouldn't apply. If the default is controlled by a sysctl, it's an administrator setting, and only an opt-in one as long as we don't change the sysctl's default value. Simplicity and consistency are key to make this mechanism useful. Administrators should not be put in a position where which options are going to be applied is not obvious to them. Once they have set the sysctl, not always obeying it is what I would think is the real POLA violation. What would be the reasons to depart from this scheme? Thanks and regards. -- Olivier Certner signature.asc Description: This is a digitally signed message part.
Re: noatime on ufs2
Hi, > Let me start out by indicating that some bike shed sessions > (snip) > Much of the overall usage is in that "additional attempted span". Ok, so it seems I've misunderstood what you were saying or your intent in this regard. > I will adjust and deal with whatever happens > overall. That is something I know I can do for my > usage context. With a sysctl knob defaulting to 'atime', you won't have to change anything. Thanks for your participation. Regards. -- Olivier Certner signature.asc Description: This is a digitally signed message part.
Re: noatime on ufs2
Hi Chris, > Honestly! Gosh... This doesn't start well. > Why do we have to upend decades of usage and understanding? Just > because it's old doesn't mean it's wrong. Who says that exactly? Separately, in case you haven't noticed yet, some things have changed in the past 50 years... > Several weeks of replies confirm my initial > belief -- atime as it is currently implemented, is as it should be. Several weeks? The first mail was sent on January 7th, my first intervention about 'noatime' being the default was on the 9th and your mail is dated the 16th. I would suggest that you revise your implementation of access times. > I haven't seen anything in this thread that wouldn't be better placed in > tuning(7) or tunefs(8). It's not really surprising since, given what you said before that, it seems that you haven't really paid attention to the messages exchanged. > Security and forensics are good reasons to keep atime unchanged. Having access times maintained may occasionally provide a bit more information, especially against script kiddies. But if you think it's a reliable source of information, you're deluded. See my response to Lyndon about the general problem with access times. I also already talked about auditing's needs in my very first mail in this thread. > Any discussion regarding changes to it's current behavior seems folly or > bikeshedding. About bike shedding, see my recent response to Mark, it applies to "folly" as well. > Apologies for the "attitude". Yeah. Most prompts imagined by Poul-Henning Kamp in his bikeshed email would have applied perfectly to your message. Thanks for the thought. -- Olivier Certner signature.asc Description: This is a digitally signed message part.
Re: noatime on ufs2
Hi Mark, > I'm confused: I go to the trouble to produce the same end result > as your suggested change of defaults would produce, ending up > with no recording of access times. That's nice of you, but unfortunately that's missing the point. First, you claimed to "seriously care" about access time, so I simply asked about your use cases, which you have not talked about. Second, your suggestions do not (in fact, cannot) produce the same end result as what I'm suggesting (change of default, or have a sysctl to control the default). I've already listed three use cases in an answer to Warner that can't be covered by modifying '/etc/fstab', and two of them that can't by just specifying mount options to mount(8) on the command-line (the auto-mounters). > My focus was on things like mount command notation and > /etc/fstab notation (that tracks mount defaults) or subroutine > interface equivalents of such things and changing their > behavior without requiring changing the notation already in > place in various files. > Nothing about that of itself > implies that I'd want the defaults for mount notation or /etc/fstab > notation or the like changed --or that I'd want them unchanged. > To narrow of a context for such a judgment about defaults. These two paragraphs seem to contradict themselves. If you've gone to the trouble mentioned above, wasn't it precisely to avoid changing the defaults? Because changing them implies that the exact same mount(8) command-line or line in '/etc/fstab' will have a different effect if 'atime' nor 'noatime' aren't explicitly specified. This is a goal, not an unwanted side effect. > In case the potential confusion is involved I'm wondering if you might be confusing default options per mount (as a line in '/etc/fstab') and system defaults applying to all mounts. By design, the former can't apply to mounts not handled by '/etc/fstab'. The latter applies in any situation, barring explicit specifications by the administrator (or delegated software), which is why it belongs to the kernel (it has to apply to the relevant system calls). > (I've tried to word the above without making new points, > avoiding contributing more to the bike shed material.) Bike shedding has become so popular in these circles that some people see bike shedding where there is none, and/or use it as a tactic to try to disqualify what others are saying. The initial bike shedding email was about a simple, obvious change to sleep(1) that prompted a flame war lasting weeks, with unfriendly fire from the project's people, sometimes from the old timers. We haven't had much of that so far, except perhaps for a few mildly aggressive or emotional emails, and the thread was active for only 10 days. It was then paused for 12 days since I didn't find time to read the latest mails and produce answers until today. What sets it apart also from the sleep(1) example is that I intended to drop an idea and gather reactions before having even produced code, because I wasn't sure on how it would be received and in particular what are the use cases that could be affected. Obtaining this feedback is essential because this project is about people from diverse backgrounds and needs. It also helps in clarifying a particular design, which some answers fulfilled. I'm now at the point where the next step is to put up some code for review for a sysctl knob. Is 'noatime' not being the default the biggest problem we currently have in FreeBSD? I agree it isn't. However, it doesn't mean there is no value in it. On the contrary, I think it is very important that the project has sane defaults that match contemporary uses: It reduces the need for tweaks, which serves both beginners but *also* seasoned administrators. This is in isolation a very small step in this direction, but there have been others and more will come. Collectively, they can build up to significant additional value for the project. Regards. -- Olivier Certner signature.asc Description: This is a digitally signed message part.
Re: noatime on ufs2
I don't
think we need to draw the line anywhere now. I like your suggestion about
covering other options. Typically, for my use cases, I would enable by default
"noatime", "nocover", "emptydir" and probably "nosuid". So the important thing
to pay attention to for an "atime"/"noatime" sysctl proposal is to name things
appropriately and factorize code to easily support other options.
> I fully agree with you regarding switching to noatime by default. I
> think this should not be done by changing the defaults in each FS. I
> think that having a sysctl only for atime/noatime is an ugly
> inconsistency (probably I wouldn't use a generic framework which handles
> all sensible mount options like that, and I think it would be overkill,
> but I wouldn't object to it).
Great. As explained above, I don't agree about the "ugly inconsistency", but
I'll make sure to pay attention to extensions to other options and try to
foresee what they entail. And also, I don't think it's overkill, both in the
sense that I'll use it all the time (and I suspect several other people as
well) and that not a lot of code is required to make it happen.
> In my opinion the correct way of handling
> it is to ask the user at install time, and existing systems shall be
> handled by those which administrate them (don't touch an existing fstab;
> changing the default in the automounter config for a .0 release would be
> OK in my opinion, for a .x release in the middle of a stable branch I
> would add a commented out noatime option to make it visible but not
> active).
I generally agree. I think the user should be able to say to the installer if
he wants "atime"/"noatime", but only if he indicates he wants to tweak the
system by choosing some "advanced" mode or something similar. Otherwise, the
default should just be 'noatime', to KISS. Once the sysctl is there, there
will be two possibilites: Either the installer changes the default, via
'loader.conf' ('sysctl.conf' is most probably handled too late during boot), or
it makes completely explicit in '/etc/fstab' what was specified (or defaulted)
during installation, so each line will have either 'atime' or 'noatime'. I'm
not sure what would be best but, not having given it much thought, a priori
would be inclined to choose the first way.
So next step for me is to propose code to have the new sysctl knob. I should
be able to present it hopefully within a few weeks (it shouldn't require more
than a couple of hours of work, it's just that I really can't find them
immediately).
Thanks and regards.
--
Olivier Certner
signature.asc
Description: This is a digitally signed message part.
Re: Removing fdisk and bsdlabel (legacy partition tools)
Hi, > A visual view of columns of a bsdlabel, editing a label using vi, checking > and double checking numbers before committing them is handy.The visual > format and the ability to adjust the numbers in an editor before committing > them is handy. You can't do this with gpart, as it's transactional. And > bsdinstall doesn't give one the opportunity to check the numbers in detail > on a console before committing them. You seem to want to be able to stack a number of modifications before actually pushing them. Actually, gpart(8) already can do that! Please see the "OPERATIONAL FLAGS" section in gpart(8). In between your tentative modifications, just use 'gpart show' to see where you stand. Thanks and regards. -- Olivier Certner signature.asc Description: This is a digitally signed message part.
Re: noatime on ufs2
Hi Mark, > I seriously care about having a lack of access times. Then, I think elaborating on your use cases would be valuable to the discussion, if by chance you want to and can share about them. Thanks and regards. -- Olivier Certner signature.asc Description: This is a digitally signed message part.
Re: noatime on ufs2
Hi Warner,
> The consensus was we'd fix it in the installer.
Isn't speaking about a "consensus", at least as a general response to the idea
of making 'noatime' the default, a little premature? I have more to say on
this topic (see below). Also, I would not dismiss Lyndon's last mail too
quickly, and in particular the last paragraph. I'm as interested as he is
about possible answers for it.
> We can't change ZFS easily, and discovery of the problem, should your
> assertion be wrong, for UFS means metadata loss that can't be recovered.
Why ZFS would need changing? If you're referring to an earlier objection from
Mark Millard, I don't think it stands, please see my response to him. Else, I
don't know what you're referring to.
If I'm understanding you correctly, strictly speaking, it's true there would be
metadata loss (access times cease to be updated). As a reminder, this only
concerns people caring about access times, and who wouldn't notice the change
in default despite it being publicized, so a small minority as we can forecast
for now. Furthermore, for the scenarios already presented, recovering exact
lost metadata is not necessary, their absence "only" complicates matters
temporarily. To know which files/packages are used, you install them and then
run your system for enough time (more or less arbitrary) before checking the
access times. Unless you're monitoring a very specific access pattern that
would be hard to reproduce, you can just repeat the experience when access
times are re-enabled. For backups, access times could be used to know which
files really matter, but then you have the option to backup them all instead
until you get the metadata for the next backup. All that assuming, as said in
an earlier mail, that nothing has messed up with the access times in the
meantime, which would ruin the feasibility of such scenarios in the first place.
> By pushing to the installer, most installations get most of benefits. And
> people with special needs see the issue and can make an informed choice.
I agree for those who use the installer. But I'm not sure which proportion of
users they represent, and especially for those who care about disabling access
times. As for me, I don't think I have used the installer in the past 10 years
(to be safe). Is this such an atypical behavior?
Additionally, the installer doesn't cover other use cases:
- Mounting filesystems by hand on USB keys or other removal medias (which are
not in '/etc/fstab'). This causes users to have to remember to add 'noatime'
on the command-line.
- Using auto-mounters. They have to be configured to use 'noatime'.
- Desktop environments shipping a mount helper. Again, they have to be
configured, if at all possible.
So limiting action to the installer, while certainly a sensible and pragmatic
step, still seems to miss a lot.
> Though in all honesty, I've never been able to measure a speed difference.
> Nor have I worn out a ssd due to the tiny increase in write amp. Old
> (<100MB) SD and CF cards included. This includes my armv7 based dns server
> that I ran for a decade on a 256MB SD card with no special settings and
> full read/write and lots of logging. So the harm is minimal typically. I'm
> sure there are cases that it matters more than my experience. And it is
> good practice to enable noatime. Just that failure to do so typically has
> only a marginal effect.
It seemed to make a difference on slow USB keys (well, not just evenly slow,
but which could exhibit strange pauses while writing), but I didn't gather
enough hard data to call that "scientific". I sometimes manage to saturate M2
SSD I/O bandwidth but then I always use 'noatime', so not sure how much a
difference it makes. The "updatedb" scenario that runs 'find' causes access
time updates for all directories, causing spikes in the number of writes which
may affect the response time during the process. That said, it is only run
once a week by default.
I would say that most of the value of having 'noatime' the default is in less
tweaking by most people, and one less thing to worry about (for them).
I proposed in another mail having a sysctl which indicates the default
('noatime' or 'atime') for all filesystems. This default would be used at
mount time if neither 'atime' nor 'noatime' is explicitly specified. That way,
people wanting 'noatime' by default everywhere could just set it to that. It
may also convince reticent people to have the default (i.e., this sysctl's
default value) changed to 'noatime', by providing a very simple way to revert
to the old behavior.
Thanks and regards.
--
Olivier Certner
signature.asc
Description: This is a digitally signed message part.
Re: noatime on ufs2
Hi Mike, > I like the idea of an option in bsdinstall, but I don't think it is necessary > to check the storage type. It could simply default to noatime. > > I think we should automatically use noatime on SD card images (where > bsdinstall > doesn't get used). One of the perhaps unappreciated point and advantage of having 'noatime' as the default is to avoid the complexity of both special casing based on media type and having to configure the different applications that can mount partitions (depending on your uses, there isn't only '/etc/fstab'). Thanks and regards. -- Olivier Certner signature.asc Description: This is a digitally signed message part.
Re: noatime on ufs2
Hi Rodney, > ... Very well said Mark ... I don't share that enthusiasm. Please see my direct response to Mark. > Please folks stop tweaking defaults, especially long standing ones, > if you feel the need for noatime, set it, by all means, I have been > for 30 years If you're implying that I have been proposing to make 'noatime' the default thoughtlessly, because I jumped in following a question by rob...@rrbrussell.com, then you couldn't be further from the truth (please see my other mails). If, despite that, this discussion bothers you, and for reasons that seem to be unrelated with the topic, what can I say? Nothing forces you to participate. Thanks at least for admitting that you're using 'noatime', as well as most of the other backers of the status quo in this discussion. Perhaps that should tell you something. Regards. -- Olivier Certner signature.asc Description: This is a digitally signed message part.
Re: noatime on ufs2
it would become easier for them to override it back. > Unless openzfs manges to decide to change that default across OSs, > in my view FreeBSD should have it be left as documented for its use > of openzfs. Given that, having FreeBSD UFS/FFS be the other way > would be problematical in my view, even ignoring defaults for > non-FreeBSD that support UFS/FFS use. Showed above to be a non-problem, see point B). Thanks and regards. -- Olivier Certner signature.asc Description: This is a digitally signed message part.
Re: noatime on ufs2
Hi Rick,
> I do not have a strong opinion w.r.t. atime, but I do believe that
> changing the default would be a POLA violation.
While I value POLA very highly, at the same time I do not consider it a
sacrosanct principle that must be followed in every possible circumstances.
There are many different ways and levels of being amazed, and varying
counterparties to gain in exchange, so there cannot be any absolute
interpretation of it. Moreover, the stricter you are in general, the more you
are pushing the project towards fossilization. It's true that there are lots
of mechanisms to allow both backwards compatibility and evolution in lots of
different cases, but they come at a cost which is increased complexity, amount
of code and configuration, which has to be taken into account as well.
Here, I do not think activating 'noatime' by default would be a significant
violation of POLA. On the contrary, I think that almost nobody will notice it,
so there barely will be any amazement. Why? First case: The user/admin
doesn't care, so is using the default. Most of them will never ever use
'atime' for any purposes. Some will try to use if a few times, discovering on
occasion that they cannot because something messed up with them (if 'atime' is
the default) or because they are not maintainted (if 'noatime' is the default).
Second case: The user/admin cares, and wants/needs to avoid the extra I/O, so
decides to uses 'noatime'. These people won't even notice a change, since they
are using 'noatime' already. Third case: The user/admin cares, and wants the
access times to be updated. If he's using an explicit 'atime', it's the same
as the previous case. If, as is likely, he's not explicit, he will notice the
change as some of his scenarios will start to fail, with more or less bad
consequences. I don't think this is really different than lots of changes the
project has gone through. The very important thing, but the only one, we would
have to do is publicizing this part correctly ("if you're relying on access
times, be sure to change your mount options, and possibly configure your
auto-mounting applications and/or other mount helpers so that 'atime' is
explicitly enabled.").
I address other POLA-related points raised by Mark Millard in a direct response
to his mail.
> Please look at this email thread, where the opinion w.r.t. atime
> seemed quite different:
> freebsd-hackers@ Oct. 5, 2023
> Subject: copy_file_range() doesn't update the atime of an empty file
>
> I'd put a url here, but gmail always puts the subject line in here when
> I copy/paste the url?
No problem, I found it online.
I only re-subscribed to hackers@ a few months ago after discovering I had been
seemingly unsubscribed for a while without knowing it.
> Basically I did not think that updating the infd's atime when
> copy_file_range()
> did not actually copy any data, but the collective disagreed, so I patched
> the NFSv4 client. (I do not know if markj@'s patch did get committed).
> They also collectively thought that Linux did a poor job w.r.t. atime.
I completely support the view that, if a copy realized through VOP_READ()
updates the access time, so should a copy realized through copy_file_range().
That is arguably also an application of POLA, but in fact here is much more: A
matter of correctness.
However I fail to see how that thread, as a whole, has any connection with the
discussion we are having. Could you please elaborate?
Thanks and regards.
--
Olivier Certner
signature.asc
Description: This is a digitally signed message part.
Re: noatime on ufs2
Hi Jamie, > I've often wished there was the ability to set a process to "noatime" - where > all accesses to the filesytem by the process and its children don't alter > atime. It would be handy for those cases you describe above, such as backups > and locate, but these days, where it matters, and is suitable, I instead > create a filesystem snapshot, and run the process on that instead. (which is > how "live" backups should be done anyway!) I've mentioned your answer in another response to Lyndon Nerenberg when developing a more general argument that 'atime' is generally flawed for these kinds of use cases (finding the last use, finding files to backup, etc.). It's true that the ability to deactivate 'atime''s implicit updates per-process would cater to more use cases, and it's an interesting idea. Essentially, though, you can't guarantee that some applications, or simply administrators typing commands at the shell, are not going to throw away your precious access times, so can't rely (in a strong sense) on them. Sure for backups and snapshots. I agree you'd better have backup perimeters coinciding with file systems partitions and use snapshots to get the smoothest possible experience. But snapshots alone do not guarantee the "correctness" of a backup (the ability to restart smoothly from it). Cheers. -- Olivier Certner signature.asc Description: This is a digitally signed message part.
Re: noatime on ufs2
Hi Lyndon, > > I've never found any compelling reason in most uses to enable "atime", > > except perhaps local mail (snip). > When UNIX ran on PDP-11s and disk pack sizes were measured in the > tens of megabytes, atime was very helpful in determining which files > were likely candidates for archiving to tape when the disk was > getting full. I appreciate this kind of historical information. According to Wikipedia, most of the PDP-11's lifespan after my birth date overlaps only with my childhood and teenage years, and I had never the chance (or curse, I don't know) to get around to one (actually, I only learned about its existence years later, much after after its phasing out). This purpose, i.e., "determine which files to archive", was achieved by relying on 'atime' I guess by selecting those whose access times were the oldest (perhaps combined with other criteria). The mean employed here is exactly the same as for the use cases reported by Warner: Being able to know which executables / libraries / packages are effectively used. So this approach has exactly the same problems. As I explained in a response to Warner, it is currently almost unpracticable on FreeBSD, because some periodic processes mess up with the access times (for more details, please read it). But more deeply, as sketched in that response, the problem is "general": Relying on access times is bound to be fragile, simply because they are updated implicitly, without the applications asking for it at all and for most neither being aware. The use cases presented for 'atime' so far all assume that the access times will be updated only on some action that is relevant to their scenarios. But you can't prevent other actions not in your scenario from updating these access times, and it can be very hard in practice to predict which can occur on a given install (depending, e.g., on how many software packages you've installed, their provenance, etc.). In some answer, Jamie Landeg-Jones suggested to have a per-process flag to control the implicit access times update, which is a workaround that is probably enough in some use cases, but not for all (see my response there). At the same time, I'd like people to realize that it is still no more than a workaround, or a "clever" way to solve one's problem in particular circumstances, but is not a generally reliable solution. What I'm evoking here concerns more the "usefulness of 'atime'" discussion than the "default should be 'noatime'", but has non-negligible bearing on the latter. > And in the Usenet days it was common to mount > /var/spool/news noatime, which eliminated a *lot* of meta-info > write traffic. A logical, completely predictable move. > These days, other than /var/mail, I can't think of a compelling use > for it. I've been running my Plan 9 systems with atime disabled > ever since fossil arrived (decades) without any impact. I agree. That's exactly the reason why I wanted to seize the occasion of rob...@rrbrussell.com's question to present my take, because I had been wondering about that a few times in the last 5 to 10 years and also never encountered a compelling reason for why it should be the default. And I insist: The initial discussion, and my main focus, is about 'noatime' becoming the default. The discussions about the usefulness of 'relatime' and 'atime' are very interesting, and I'm even participating to those, but to me are secondary in the end. The usefulness of 'atime' is of course in part connected to the default to use, but they are still very different questions. For example, concerning the former, the frequency of needs (how many uses?) is not very important, whereas it matters a lot when it comes to which default to choose. > I don't see any issue with making noatime the default. For those > that must have it, /var/mail can be carved out as a distinct > filesystem and mounted appropriately. The summary of the technical side of this discussion so far is that there most likely won't be any issue at all for the vast majority of users if 'noatime' becomes the default. We'll see if more reports for other scenarios are to come (or if we can find or guess some ourselves; irrespective of whether they validate or not the current evaluation). And, as reported by others, even /var/mail should not need it in most uses given that all prominent MUAs have long departed from using the access time comparison alone. (I won't pronounce myself on this since I'm not personally using them, but I'm not seeing any reason not to trust the reports. If some people have contradictory facts, I hope that they will present them.) Thanks and regards. -- Olivier Certner signature.asc Description: This is a digitally signed message part.
Re: noatime on ufs2
> > Again, I'm not opposing anyone from working on "relatime" if they > > personally have a strong need and motivation. I'm not even asking for > > removing the "atime" functionality, which can have its uses. > > > > Yea, relatime has some interesting use cases: Is this binary / library in > use is one such case. The fact that you've completely omitted that use case > suggests that the analysis of atime's usefulness (or its lack) is at least > incomplete. Yes, but I never pretended to have completely analyzed the usefulness of 'atime'. See "which can have its uses" above. But I think there is already enough matter for the case of the *default value* for 'atime'. > relatime would work great on /usr/local where you have a lot of programs: > you reduce a lot of traffic. It's quite useful to know what packages are in > use or not based on when they were last accessed, not just last installed. Both the examples above prompt some straight objections on the current usefulness of "atime". First, unless you've disabled building the locate database in cron (enabled by default, on a weekly basis), access times on directories lose most of their usefulness. Second, if using an IDS, I'm afraid it's just game over. And even if you think you are not, '460.pkg-checksum' at least is readily there to much complicate, or even prevent you from, getting package usage information this way (it is enabled by default, and on a daily basis). The general point here is that a single access time is inherently fragile to interferences by multiple applications for multiple reasons. > I'm not sure this is a great notion to have everywhere. I think your > analysis needs more inputs. May be, but to me the case for the default value debate at least seems quite strong already. Regards. -- Olivier Certner signature.asc Description: This is a digitally signed message part.
Re: noatime on ufs2
> This is an interesting type of argument. Except this is not an argument to the main discussion, as apparently you haven't understood? This kind of response is disingenuous. Either you said too much, or you didn't say enough. -- Olivier Certner signature.asc Description: This is a digitally signed message part.
Re: noatime on ufs2
Hi Warner, > It has also been used for almost as long to see if log files have changed > if you set your MAIL variable to that. So not just for email... This seems to be an example in point of a "niche" scenario, both in terms of spread of usage (even then) and the fact that it's easy to get the functionality by other means. Again, I'm not opposing anyone from working on "relatime" if they personally have a strong need and motivation. I'm not even asking for removing the "atime" functionality, which can have its uses. What I'm saying is that, based on others' input so far, my own (long, even if not as long as yours) experience and some late reflection, is that "noatime" should be the default (everywhere, all mounts and all FSes), and that working on "relatime" won't make any real difference for most users (IOW, I think that developing "relatime" is a bad idea *in general*). And I think this is a sufficiently reasonable conclusion that anyone with the same inputs would conclude the same. So, if it's not the case, I would be interested in knowing why, ideally. Regards. -- Olivier Certner signature.asc Description: This is a digitally signed message part.
Re: noatime on ufs2
Hi, > I would not exactly call this a gimmick. I wish I hadn't used that term since it attracts too much attention on itself, making people forget it was part of a sentence that was quite balanced and seemingly altering their judgement. I think you're confusing the need and the mechanism (or implementation). In substance, we (Robert and I) were talking about turning "atime" off *by default*. What I tried to convey is that the needs that justify this mechanism are those of a minority in my view (and I'm certainly not opposed to be educated if it's not true), and additionally that the "atime" mechanism addresses these needs poorly. With that in mind, developing "relatime" to try to alleviate the shortcomings of "atime" has a low ROI: It doesn't add the crucial functionality most needs (like auditing) would require and doesn't even really address the I/O shortcomings in some frequent scenarios. Deactivating "atime", by contrast, doesn't require any development, suppresses all I/O overhead, and doesn't suppress any functionality for an overwhelming majority of uses (at least, this is my current view; other inputs welcome). I did not say that the needs themselves are a gimmick, e.g., having a notification of new mail (although, in this case, frankly, I'm on the verge of arguing it). Simply, relying on "atime" (or "relatime") for this is unnecessary, as you must have understood reading the various previous answers in this thread. > On Linux mount(8) from https://github.com/karelzak/util-linux says > >relatime >Update inode access times relative to modify or change time. Access >time is only updated if the previous access time was earlier than >or equal to the current modify or change time. (Similar to noatime, >but it doesn’t break mutt(1) or other applications that need to >know if a file has been read since the last time it was modified.) > > and this is what i use, except for some noatime mount points > (/x/doc, /x/music, /x/pub, to be exact). It seems that the other answers (mostly those of Robert IIRC) have shown that this manpage text isn't up-to-date with current practices. Which need(s) of yours are you trying to address exactly by using "relatime"? Thanks and regards. -- Olivier Certner signature.asc Description: This is a digitally signed message part.
Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule
Hi Glen, > I also agree we cannot prevent people from downloading the images, > installers, whatever before the announcement. That is the lovely race > condition with which we have to live at the moment. Yes, and given that, I don't think you did anything wrong. It seems that the race is the same for freebsd-update(8), according to "The Doctor". But maybe in this case it is easier to fix, perhaps if installing the metadata signaling the new release to it can be delayed, by contrast with big files containing the actual data (I don't know how freebsd-update(8) works, so this is just a guess). > The alternative would be to say nothing at all. I really hope you and re@ will never choose this way. > Either way, it is a productivity, communication drain. It is > a lose-lose situation no matter how one looks at it given the above > context. We either get chastised for being "too open" into insights > delaying an official announcement, or for being "not open enough" when > there is silence from RE when a release does not meet its scheduled > announcement date. IMHO, a delay should always be announced (perhaps unless it's only a few days). If it is too hard to decide on the right level of details, then only mention that some (potential or verified) problem is being looked upon, but don't let that prevent you from communicating. As for people saying that they have already installed the "release", I'd suggest to have some text on the website (https://www.freebsd.org/releng/ perhaps) explaining that images on mirrors can appear in advance of release announcements and that they should not be considered as official until the official mail is sent, and just kindly point them to it. I hope this can contribute to at least attenuating the drain you're experiencing. Regards. -- Olivier Certner
Re: something magic about the size of a ports tree
Hi Matthias, Some ZFS dataset with zstd compression on jet, and no compression on c720-1400094? -- Olivier Certner
Re: huge amount laundry memory not being cleaned up
Le mardi 11 juillet 2023, 01:51:02 CEST Pete Wright a écrit : > sorry for the noise folks, this is almost certainly an issue with my > local env. this is helpful for me, as i'll have a better idea as to > where i should focus my efforts trying to find this memory hog next time. I have had what I suspect to be the same issue on 13.2-STABLE with KDE and very long sessions. I say "suspect" since I seem to remember that laundry usage went down by unlogging (or restarting kwin or plasmashell), but I'm not completely sure now. So may not be specific to your local env after all, nor to CURRENT. Regards. -- Olivier Certner
Re: RFC: nfsd in a vnet jail
> To enforce it for cases where mountd/nfsd is not being run would > definitely be a POLA violation. I could not agree more. Thanks for the clarification. -- Olivier Certner
Re: RFC: nfsd in a vnet jail
Hi, > (snip) > > #2 - Require separate file systems and run mountd inside the jail(s). > > I think that allowing both alternatives would be too confusing > and it seems that most want mountd to run within the jail(s). > As such, unless others prefer #1, I think #2 is the way to go. Just to be sure I've understood correctly: You plan to make a separate filesystem as jail's root a requirement but only in the case of using mountd(8) in the jail? Or in general? While I think doing so in the NFSv4/mountd case is indeed a good idea, I don't think enforcing it in general is. It would generally degrade the multiple jails management experience on UFS (in the absence of a volume manager), where all jails have roots in the same filesystem (to avoid allocating/deallocating space as jails come and go or must be resized). Regards. -- Olivier Certner
Re: loader.efi module path vs kernel directory
Hi Andriy, > if you escape to prompt directly loader didn't loaded all it's config > so there is no modulepath defined, you need to 'boot-conf' to load the > configuration files. You might prefer to use 'read-conf' instead of interrupting 'boot-conf''s countdown. Regards. -- Olivier Certner
Re: Please check the current beta git conversions
> Receiving objects: 100% (3763254/3763254), 1.10 GiB | 876.00 KiB/s, done. > Executed in 30.36 mins Experienced a comparable full clone time yesterday afternoon from France (did not precisely `time` it). The bandwidth oscillated between 600 and 1.2MiB/s steadily during the transfer. The final reported bandwidth was 991KiB/s (same transfer size). -- Olivier Certner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Please check the current beta git conversions
Hi, > > 2.5 GB in .git directory sounds crazy and incomprehensible to me. > > 2.5GB is for the full history, if you only care about the main branch, > you can clone with: > > (snip) I do not reproduce this, but instead see `du` reporting 1.2GiB just after a simple clone (no options), which AFAIK contains the whole history. I have a complete mirror of SVN that I update with scripts around `svnrdump dump` and `svnadmin load`, and its size is 6.1GiB (I pack it regularly). For the record, here are the sizes of the `.svn` directories of some checkouts I currently have: - stable/12 at rev 355888: 1.9GiB - stable/12 at rev 361580: 2.4GiB - head at rev 361584: 2.7GiB I must point out that I don't remember the exact creation history of these. It is probable that, to create new ones, I did full copies (`cp -a`) of an old one followed by `svn switch`. Don't know if this can have an influence on these numbers (didn't test with pristine checkouts). Important tip: When using `du`, don't forget to pass the '-A' option, especially if using ZFS + compression. -- Olivier Certner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Recent GELI additions.
Hi, Thanks a lot for your efforts, Pawel! Geli is definitely awesome. Bye, Olivier Certner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
