Re: noatime on ufs2
Am 2024-01-15 00:08, schrieb Olivier Certner: 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. ZFS by default has atime=on. It is our installer which sets atime=off in the ZFS properties. I was understanding Warners comment about changing ZFS in the sense of changing the ZFS code to have a default of atime=off. I agree with Warner that we should not do that. And in my opinion we should keep the other FS which support atime/noatime consistent (those which don't support atime/noatime due to technial limitations don't count in my opinion). 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? I haven't used an installer myself since longer (either I was creating a new system by attaching a disk and prepping it from an existing system, or by creating an image and transferring it to the target over the network). But I would say this is atypical behavior by people which know exactly what they are doing, not what a normal consumer would do. Such experts know exactly what they want to do with atime and handle it as needed. 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. Those which care about that and know where this makes a difference, have it in their finger-memory. - Using auto-mounters. They have to be configured to use 'noatime'. If our automounter is not able to handle that, it is a bug / missing feature we can change. Personally I would have no objection to changing the automounter config to mount with noatime (if specifying noatime for a FS which don't support atime/noatime doesn't create failures). - Desktop environments shipping a mount helper. Again, they have to be configured, if at all possible. If they are not able to handle that, it is a bug. Typical media in desktop use-cases doesn't really need this. If you handle media which really _needs_ noatime in such a case, you may want to reconsider your way of operating. So limiting action to the installer, while certainly a sensible and pragmatic step, still seems to miss a lot. Nobody told to only limit this action to the installer. The pragmatic part here is to ask if it really matters for those use cases. For mounting by hand I disagree that it matters. For our automounter we should do something (at least making sure it is able to handle it, and if we don't want to swtich the default at least have a commented out entry in the config with a suitable comment). For the desktop helpers it is not our responsability, but interested people surely can file a bug report upstream. 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
Re: noatime on ufs2
Am Sun, 14 Jan 2024 19:14:16 +0100 schrieb "Patrick M. Hausen" : > That number at first looks like a serious load on the write endurance > of your SSD. Then, doing the math it turns out it's absolutely > ridiculous. > > 100 kB/s sums up to 8,640 GB/day (in decimal units). Even the small > SSDs typically used for embedded devices like firewalls (32 or 64 G > capacity) have a write endurance in the order of 100 or 200 TBW. > > That's more than 10.000 days or roughly 30 years ... This highly depends on how your written data are distributed on the disk. I have seen cases of write amplification by orders of magnitude, e.g., when adding few bytes on many (several 10k) different files. cu Gerrit smime.p7s Description: S/MIME cryptographic signature
Re: NFSv4 crash of CURRENT
Am Sun, 14 Jan 2024 20:34:12 -0800 Cy Schubert schrieb: > In message om> > , Rick Macklem writes: > > On Sat, Jan 13, 2024 at 12:39=E2=80=AFPM Ronald Klop = > > wrote: > > > > > > > > > Van: FreeBSD User > > > Datum: 13 januari 2024 19:34 > > > Aan: FreeBSD CURRENT > > > Onderwerp: NFSv4 crash of CURRENT > > > > > > Hello, > > > > > > running CURRENT client (FreeBSD 15.0-CURRENT #4 > > > main-n267556-69748e62e82a= > > : Sat Jan 13 18:08:32 > > > CET 2024 amd64). One NFSv4 server is same OS revision as the mentioned > > > cl= > > ient, other is FreeBSD > > > 13.2-RELEASE-p8. Both offer NFSv4 filesystems, non-kerberized. > > > > > > I can crash the client reproducable by accessing the one or other NFSv4 > > > F= > > S (a simple ls -la). > > > The NFSv4 FS is backed by ZFS (if this matters). I do not have physicla > > > a= > > ccess to the client > > > host, luckily the box recovers. > > Did you rebuild both the nfscommon and nfscl modules from the same sources? > > I did a commit to main that changes the interface between these two > > modules and did bump the > > __FreeBSD_version to 1500010, which should cause both to be rebuilt. > > (If you have "options NFSCL" in your kernel config, both should have > > been rebuilt as a part of > > the kernel build.) > > > > Is anyone by chance seeing autofs in the backtrace too? > > Hello Cy Shubert, I forgot to mention that those crashes occur with autofs mounted filesystems. Good question, by the way, I will check whether crashes also happen when mounting the tradidional way. Kind regards, oh -- O. Hartmann
Re: NFSv4 crash of CURRENT
In message , Rick Macklem writes: > On Sat, Jan 13, 2024 at 12:39=E2=80=AFPM Ronald Klop = > wrote: > > > > > > Van: FreeBSD User > > Datum: 13 januari 2024 19:34 > > Aan: FreeBSD CURRENT > > Onderwerp: NFSv4 crash of CURRENT > > > > Hello, > > > > running CURRENT client (FreeBSD 15.0-CURRENT #4 main-n267556-69748e62e82a= > : Sat Jan 13 18:08:32 > > CET 2024 amd64). One NFSv4 server is same OS revision as the mentioned cl= > ient, other is FreeBSD > > 13.2-RELEASE-p8. Both offer NFSv4 filesystems, non-kerberized. > > > > I can crash the client reproducable by accessing the one or other NFSv4 F= > S (a simple ls -la). > > The NFSv4 FS is backed by ZFS (if this matters). I do not have physicla a= > ccess to the client > > host, luckily the box recovers. > Did you rebuild both the nfscommon and nfscl modules from the same sources? > I did a commit to main that changes the interface between these two > modules and did bump the > __FreeBSD_version to 1500010, which should cause both to be rebuilt. > (If you have "options NFSCL" in your kernel config, both should have > been rebuilt as a part of > the kernel build.) > Is anyone by chance seeing autofs in the backtrace too? -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0
Re: noatime on ufs2
On Jan 14, 2024, at 15:15, Olivier Certner wrote: > 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. 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. 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. In case the potential confusion is involved, I'll quote another reply that I just made relative to more potential use of notime: QUOTE I've not reported any objection to bsdinstall having explicit choices required in its menus. Nor to changing how, say, official snapshots are generated (so long as well notified and documented). If my wording was unclear on that, I'm sorry. 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. (I've tried to word the above without making new points, avoiding contributing more to the bike shed material.) END QUOTE === Mark Millard marklmi at yahoo.com
Re: noatime on ufs2
On Jan 14, 2024, at 14:27, Tomoaki AOKI wrote: > On Sun, 14 Jan 2024 10:53:34 -0800 > Mark Millard wrote: > >> On Jan 14, 2024, at 08:39, Olivier Certner wrote: >> >>> Hi Mark, >>> I never use atime, always noatime, for UFS. That said, I'd never propose changing the long standing defaults for commands and calls. >>> >>> With this mail, you're giving more detailed objections on the >>> social/political aspects of the proposed changed, or as we usually say more >>> simply, POLA. >>> >>> All your points are already largely weakened by the fact that, to wrap-up >>> in a single sentence at the risk of being slightly caricatural (but then >>> see my other mails), nobody really seems to care seriously about access >>> times. >> >> I seriously care about having a lack of access times. Yet, I've no >> objection to needing to be explicit about it in commands and >> subroutine interfaces, given the long standing interfaces (defaults). >> It would be different if I could not achieve the lack of access >> times. That defaults do not block having the desired settings makes >> the change optional, not technically required. The defaults are, >> thus, primarily social/political aspects of interfaces, not >> technical requirements to make things work. >> >> Given that, I explicitly claim that avoiding POLA at this late stage >> is my preference for the priority of competing considerations. I >> make no claim of knowing the majority view of the tradeoffs. I would >> claim that, if the majority is not by just some marginal amount, >> contradicting that majority view for this would not be appropriate. >> (Again: the social/political aspects.) >> >> And, hopefully, this is my last contribution to this particular >> bike shed. >> >> === >> Mark Millard >> marklmi at yahoo.com > > I would prefer violating POLA here, with, for example, forcing admins > to choose explicitly with installer menu I've not reported any objection to bsdinstall having explicit choices required in its menus. Nor to changing how, say, official snapshots are generated (so long as well notified and documented). If my wording was unclear on that, I'm sorry. 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. (I've tried to word the above without making new points, avoiding contributing more to the bike shed material.) > Choose whether you need to retain last file access time or not: >1: Don't keep(current default) >2: Keep last one (default before 15.0) > > by hand, or via installer configuration or additional scripts. > Of course, existing installations should not be affected. > === Mark Millard marklmi at yahoo.com
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
Olivier Certner wrote: > 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. Thanks for the heads-up - I've only now had a chance to catch up with the thread. You are of course right - atime can be affected by so many different things that it can't be relied upon. I just thought a per-process method would be a good compromise to avoid blanket atime changes across the system - both for atime usefulness, and I/O, but as you say, as it's unreliable to rely on anyway, this solution may be making things worse by giving a false sense of reliability. And to further bolster your point, whilst I have wished for more granuality with respect to controlling atime updates, for years I've run everything with noatime.. Even when I thought it was nice to keep atime relatively accurate, I soon realised that I simply never used it anyway! > 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). Yeah, it's more like a snapshot at the time of a power failure, but of course, it's better than running on a live filesystem because a file may be missed completely if moved whilst the backup is running. But short of shutting everything down prior to taking the snapshot (I remember at last job some very old machines without snapshotting or decent db journalling capabilities being taken down for hours every night, so that the whole backup ran in a minimal boot environment!), I don't know of a cleaner solution... (though I'm sure some exist.. after all, live migrations between hosts are a thing these days.. I guess I need to do some homework on the matter! :-) ) Thanks again, Jamie
Re: noatime on ufs2
On Sun, 14 Jan 2024 10:53:34 -0800 Mark Millard wrote: > On Jan 14, 2024, at 08:39, Olivier Certner wrote: > > > Hi Mark, > > > >> I never use atime, always noatime, for UFS. That said, I'd never propose > >> changing the long standing defaults for commands and calls. > > > > With this mail, you're giving more detailed objections on the > > social/political aspects of the proposed changed, or as we usually say more > > simply, POLA. > > > > All your points are already largely weakened by the fact that, to wrap-up > > in a single sentence at the risk of being slightly caricatural (but then > > see my other mails), nobody really seems to care seriously about access > > times. > > I seriously care about having a lack of access times. Yet, I've no > objection to needing to be explicit about it in commands and > subroutine interfaces, given the long standing interfaces (defaults). > It would be different if I could not achieve the lack of access > times. That defaults do not block having the desired settings makes > the change optional, not technically required. The defaults are, > thus, primarily social/political aspects of interfaces, not > technical requirements to make things work. > > Given that, I explicitly claim that avoiding POLA at this late stage > is my preference for the priority of competing considerations. I > make no claim of knowing the majority view of the tradeoffs. I would > claim that, if the majority is not by just some marginal amount, > contradicting that majority view for this would not be appropriate. > (Again: the social/political aspects.) > > And, hopefully, this is my last contribution to this particular > bike shed. > > === > Mark Millard > marklmi at yahoo.com I would prefer violating POLA here, with, for example, forcing admins to choose explicitly with installer menu Choose whether you need to retain last file access time or not: 1: Don't keep(current default) 2: Keep last one (default before 15.0) by hand, or via installer configuration or additional scripts. Of course, existing installations should not be affected. -- Tomoaki AOKI
Re: noatime on ufs2
On Jan 14, 2024, at 08:39, Olivier Certner wrote: > Hi Mark, > >> I never use atime, always noatime, for UFS. That said, I'd never propose >> changing the long standing defaults for commands and calls. > > With this mail, you're giving more detailed objections on the > social/political aspects of the proposed changed, or as we usually say more > simply, POLA. > > All your points are already largely weakened by the fact that, to wrap-up in > a single sentence at the risk of being slightly caricatural (but then see my > other mails), nobody really seems to care seriously about access times. I seriously care about having a lack of access times. Yet, I've no objection to needing to be explicit about it in commands and subroutine interfaces, given the long standing interfaces (defaults). It would be different if I could not achieve the lack of access times. That defaults do not block having the desired settings makes the change optional, not technically required. The defaults are, thus, primarily social/political aspects of interfaces, not technical requirements to make things work. Given that, I explicitly claim that avoiding POLA at this late stage is my preference for the priority of competing considerations. I make no claim of knowing the majority view of the tradeoffs. I would claim that, if the majority is not by just some marginal amount, contradicting that majority view for this would not be appropriate. (Again: the social/political aspects.) And, hopefully, this is my last contribution to this particular bike shed. === Mark Millard marklmi at yahoo.com
Re: noatime on ufs2
Hi folks, that's a really interesting polite and constructive discussion going on here, and a trip down history lane to boot :-) I just want to add one thing to Warner's last argument: > Am 14.01.2024 um 18:58 schrieb Warner Losh : > 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. Recently on the OPNsense forum somehow an increasing number of users started to post worried questions regarding a constant write load on the system disk/SSD in the order of 100 kB/s or some small multitude thereof. Definitely smaller than 1MB/s. That number at first looks like a serious load on the write endurance of your SSD. Then, doing the math it turns out it's absolutely ridiculous. 100 kB/s sums up to 8,640 GB/day (in decimal units). Even the small SSDs typically used for embedded devices like firewalls (32 or 64 G capacity) have a write endurance in the order of 100 or 200 TBW. That's more than 10.000 days or roughly 30 years ... That's why I like following this discussion and every improvement is in then end an improvement, but I consider it mostly a micro optimisation. Kind regards, Patrick P.S. I don't use atime anywhere I knew.
Re: noatime on ufs2
Warner Losh writes: > > I'm really interested in hearing from people who actively use > > atime on a regular basis for non-trivial purposes. What are > > the modern use cases for atime? > The consensus was we'd fix it in the installer. Sure, but my question still stands. I'm genuinely curious to know how (or if) people still use atime. --lyndon
Re: noatime on ufs2
On Sun, Jan 14, 2024, 10:24 AM Lyndon Nerenberg (VE7TFX/VE6BBM) < lyn...@orthanc.ca> wrote: > > > I do not have a strong opinion w.r.t. atime, but I do believe that > > > changing the default would be a POLA violation. > > I'm not prepared to just accept that at face value. > > I can't think of a single instance in at least the last three decades > where I have actually used or needed atime for *anything*. And > over that time period I have been responsible for running hundreds > of UNIX servers. > > I'm really interested in hearing from people who actively use > atime on a regular basis for non-trivial purposes. What are > the modern use cases for atime? > The consensus was we'd fix it in the installer. 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. 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. 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. Warner --lyndon > >
Re: noatime on ufs2
> > I do not have a strong opinion w.r.t. atime, but I do believe that > > changing the default would be a POLA violation. I'm not prepared to just accept that at face value. I can't think of a single instance in at least the last three decades where I have actually used or needed atime for *anything*. And over that time period I have been responsible for running hundreds of UNIX servers. I'm really interested in hearing from people who actively use atime on a regular basis for non-trivial purposes. What are the modern use cases for atime? --lyndon
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
Hi Mark,
> I never use atime, always noatime, for UFS. That said, I'd never propose
> changing the long standing defaults for commands and calls.
With this mail, you're giving more detailed objections on the social/political
aspects of the proposed changed, or as we usually say more simply, POLA.
All your points are already largely weakened by the fact that, to wrap-up in a
single sentence at the risk of being slightly caricatural (but then see my
other mails), nobody really seems to care seriously about access times.
Please read my response to Rick Macklem on POLA, it is already a general answer
to all of them.
Additionally, I have some specific answers or remarks.
> I'd avoid:
> A) Having natives & required file systems with mismatching defaults.
> ("required" is for spanning efi/msdosfs partitions if the atime/noatime
> makes a distinction there. So not just UFS/FFS and ZFS.)
The proposed change is general to the system, irrespective of partition types
or mount points, so it doesn't have this problem.
> B) Having files systems that are not OS specific have unusual defaults
> compared to those other OS's when there is documented uniformity.
> (openzfs being such an example file system.)
The only example I think you can have of this is ZFS, and contrary to what you
think is in fact not a problem because of its peculiarities.
ZFS stores 'atime' as a filesystem attribute ("property"). It automatically
uses its (boolean) value at mount, unless overridden by explicit mount options,
so no default value is relevant here.
Properties of a dataset are inherited from parents if not set explicitly (well,
this is not true for statistics native properties, but 'atime' is not one of
them, it is a control one). So, if the value of 'atime' is reported by ZFS for
some dataset as coming from a "default" source, necessarily the root dataset is
using the same value. Consequently, the only place where the default value (as
seen by ZFS) matters is the root dataset.
Thus, the only sensible meaning of "having 'noatime' as the default behavior"
for ZFS amounts to setting the 'atime' property to off on the root dataset on
zpool creation. By doing so, all datasets will inherit the value, unless
explicitly overriden. After the zpool creation, each dataset's value of
'atime' cannot be influenced by the system default at all, as is the case for
all other similar properties (this is the way ZFS works). In this scheme, it
is necessary that OpenZFS keeps its own default value, in case ZFS pools
created on other systems are imported on FreeBSD. The only change with respect
to current pools is that 'zfs get atime' on the root dataset will return a
'local' source instead of 'default'. And that's all. No change is necessary
in ZFS.
> C) Having defaults unlike most other closely related operating systems
> that support the file system when there is generally documented
> uniformity. (No claim to have checked on the uniformity generally.)
> (Other BSDs, Unix, Linux, . . .)
I didn't check these, but I would bet they all activate 'atime' by default, for
"historical reasons". I understand the fear here would be cognitive burden,
but again in most cases it won't happen in practice. If you take again the 3
cases developed in the response to Rick, you'll see that only people who really
care about having 'atime' are concerned and should change their habits, and so
far it seems it's by far the smallest group, and with no significant/compelling
use case. People who want 'noatime' and are used to using it can continue to
do so without any change. People who don't care, well... don't care.
> D) Having defaults for non-native files systems that are different than
> the native contexts for the file system have when they have uniformity.
> (So, for example, linux ext4 use would get linux etx4 default behavior
> for atime vs. noatime if such is basically uniform across most
> linux's.)
This point is an additional reason why the default should be per system and not
by filesystem.
As I was writing the word "system", with its ambiguity (does it mean an
operating system, or a particular machine?), I've just had another, simple
idea: Create a system-wide sysctl knob controlling the default. This would
already allow administrators that care to set the value they want in a single
place, and not have to tweak the mount point options, the configuration of
auto-mounters and other applications mounting filesystems. This doesn't say
anything on the problem of FreeBSD's default value, which then becomes that of
the default value for the knob. However, the availability of the knob, besides
its own usefulness, may convince reluctant people, which logically should be
those that care about 'atime', to accept 'noatime' as the default, since it
would become easier for them to override it back.
> Unless openzfs manges to decide to change that default across
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: IPFW/IPv6 problem with JAIL: JAIL cannot ping -6 host until host first pings jail (ipv6)
Am Mon, 8 Jan 2024 01:33:53 +0100 (CET) Felix Reichenberger schrieb: > > Hello, > > > > I've got a problem with recent CURRENT, running vnet JAILs. > > FreeBSD 15.0-CURRENT #28 main-n267432-e5b33e6eef7: Sun Jan 7 13:18:15 CET > > 2024 amd64 > > > > Main Host has IPFW configured and is open for services like OpenLDAP on > > UDP/TCP and ICMP > > (ipfw is configured via rc.conf in this case, host is listening on both > > protocol families > > IPv4 and IPv6). > > > > The host itself has openldap-server 2.6 as a service. The host's interface > > is igb0 with > > assigned ULA. JAILs (around eight jails) are sharing their vnet interfaces > > via a bridge > > with the same physical device as the host (igb0). After a while (the time > > elapsed is > > unspecific) the jail is unable to contact the host via IPv6: neither UDP, > > TCP nor ICMP > > sent from the JAIL is reaching the host. IPv4 is working like a charme! No > > problems there. > > > > When pinging the Jail from the main host via ping -6, the jail is > > responding! After the > > first ping -6, the jail now is able to ping -6 the main host. > > > > After a fresh reboot, the problem is not present and occurs after a while > > and it seems to > > happen first to very active jails. > > > > Kind regards, > > > > oh > > > > > > -- > > O. Hartmann > > > > Hello, > > This behavior might be caused by IPFW blocking some IPv6 neighbor > discovery/advertisement > messages. > After some time, the link layer addresses of the IPv6 neighbors in the NDP > cache may expire, > making the associated IPv6 addresses inaccessible. > Do your IPFW rules allow ICMPv6 messages to and from IPv6 multicast addresses? > > Regards. > Thank you for responding. Thank you for his valuable hint! The jail(s) itself/themselfes as well as the host use the regular ipfw rc setup script as provided with the base system, adding simply those ports open which provide services - a plain and simple approach. Checking the jails on the host in question (jails are contacting OpenLDAP server on host, OpenLDAP server configured for test purposes to listen only on IPv6) leaves me with inconclusive results. Assuming a jail, called host-git, and a host, master. Deleting the NDP entries aon hostgit via "ndp -c" leaves me with the initial reported issue here, the solution is to ping the host-git first from host-master to "magically open" the IPv6 connection. After that, ldapsearch or any other IPv6 connections originating on the host-git work again. That seems odd. jails are vnet. Jails reside on a bridgeXX interface, sharing the physical NIC of the master host. Just for the record. I use a similar setup on a XigmaNAS host (13.2-RELEASE-p8), also with active IPFW on the master host's side as well as IPFW enabled on the Jail's side. Difference to the above mentioned setup: The jail is located on a different host, contacting master-host via a switched network. Regards, oh -- O. Hartmann
Re: NFSv4 crash of CURRENT
Am Sat, 13 Jan 2024 19:41:30 -0800 Rick Macklem schrieb: > On Sat, Jan 13, 2024 at 12:39 PM Ronald Klop wrote: > > > > > > Van: FreeBSD User > > Datum: 13 januari 2024 19:34 > > Aan: FreeBSD CURRENT > > Onderwerp: NFSv4 crash of CURRENT > > > > Hello, > > > > running CURRENT client (FreeBSD 15.0-CURRENT #4 main-n267556-69748e62e82a: > > Sat Jan 13 > > 18:08:32 CET 2024 amd64). One NFSv4 server is same OS revision as the > > mentioned client, > > other is FreeBSD 13.2-RELEASE-p8. Both offer NFSv4 filesystems, > > non-kerberized. > > > > I can crash the client reproducable by accessing the one or other NFSv4 FS > > (a simple ls > > -la). The NFSv4 FS is backed by ZFS (if this matters). I do not have > > physicla access to > > the client host, luckily the box recovers. > Did you rebuild both the nfscommon and nfscl modules from the same sources? Yes, as requested, as soon as the commit occured. I recompiled the whole OS from a "make -j4 cleanworld cleandir" . But I have a custom kernel with several custom options statically compiled in. > I did a commit to main that changes the interface between these two > modules and did bump the > __FreeBSD_version to 1500010, which should cause both to be rebuilt. > (If you have "options NFSCL" in your kernel config, both should have > been rebuilt as a part of > the kernel build.) Monday I will try to compile in several debug options whe I get hands on the machine again and I can test Tuesday on several other boxes running CURRENT (after update) how they interact with themselfes (CURRENT) and other (FBSD14, FBSD13) via NFSv4. > > rick > > > > I have no idea what causes this problem ... > > > > Kind regards, > > > > O. Hartmann > > > > > > -- > > O. Hartmann > > > > > > > > > > > > Do you have something like a panic message, stack trace or core dump? > > > > Regards > > Ronald > -- O. Hartmann
