Re: noatime on ufs2
Am 2024-01-10 22:49, schrieb Mark Millard: I never use atime, always noatime, for UFS. That said, I'd never propose changing the long standing defaults for commands and calls. I'd avoid: [good points I fully agree on] There's one possibility which nobody talked about yet... changing the default to noatime at install time in fstab / zfs set. I fully agree to not violate POLA by changing the default to noatime in any FS. I always set noatime everywhere on systems I take care about, no exceptions (any user visible mail is handled via maildir/IMAP, not mbox). I haven't made up my mind if it would be a good idea to change bsdinstall to set noatime (after asking the user about it, and later maybe offer the possibility to use relatime in case it gets implemented). I think it is at least worthwile to discuss this possibility (including what the default setting of bsdinstall should be for this option). Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF signature.asc Description: OpenPGP digital signature
Re: route ipv6 errors on bootup in -current main-n267425-aa1223ac3afc on arm64
> On Jan 9, 2024, at 6:24 PM, void wrote: > > On Mon, Jan 08, 2024 at 01:07:30PM -0800, Enji Cooper wrote: >> >> Was the kernel/utility built with IPv6? If not, that’s a general bug which >> should be filed (which can be easily checked/avoided using the FEATURES(9) >> subsystem)… >> Cheers! >> -Enji > > world/kernel was built with WITHOUT_INET6= in /etc/src.conf > > I made the problem go away with removing WITHOUT_INET6= and rebuilding. > The system was installed by taking > FreeBSD-15.0-CURRENT-arm64-aarch64-RPI-20240104-8bf0882e186e-267378.img > and dd-ing it to a usb3-connected hd. > > Where can I read about features? Features can be retrieved by `sysctl kern.features`. As for INET6 it should be `kern.features.inet6` . > > % man features > No manual entry for "features" > > it's not in apropos > thanks, > -- > Best regards, Zhenlei
poudriere: swap_pager: out of swap space
hi list, i'm having a recurring problem with poudriere that i hope someone might have an idea about. i'm building packages with poudriere on a system with 32GB memory, with tmpfs and md disabled in poudriere (so it's using ZFS only) and with the ZFS ARC limited to 8GB. running poudriere produces many kernel log messages like this: Jan 10 21:40:00 ilythia kernel: swap_pager: out of swap space Jan 10 21:40:00 ilythia kernel: swp_pager_getswapspace(2): failed Jan 10 22:41:55 ilythia kernel: swap_pager: out of swap space Jan 10 22:41:55 ilythia kernel: swp_pager_getswapspace(21): failed Jan 10 23:48:03 ilythia kernel: swap_pager: out of swap space Jan 10 23:48:03 ilythia kernel: swp_pager_getswapspace(8): failed Jan 11 00:05:00 ilythia kernel: swp_pager_getswapspace(1): failed Jan 11 00:21:45 ilythia kernel: swp_pager_getswapspace(10): failed this is despite the system having a large amount of "Inact" memory according to top(1): Mem: 3828M Active, 15G Inact, 2921M Laundry, 9263M Wired, 1559M Buf, 892M Free ARC: 3113M Total, 994M MFU, 884M MRU, 39M Anon, 49M Header, 1139M Other 1296M Compressed, 4130M Uncompressed, 3.19:1 Ratio Swap: 2048M Total, 2048M Used, 8192B Free, 99% Inuse from what i can tell, these swap errors don't cause any issues with the poudriere build, but they do seem to hinder interactive usage by causing long hangs. does anyone have some idea what's going on here? i don't really understand why the system has used 100% of available swap space when it has plenty of Inact memory it could free to fulfill requirements. signature.asc Description: PGP signature
Re: noatime on ufs2
On Thu, Jan 11, 2024 at 1:50 AM Rodney W. Grimes wrote: > > Olivier Certner wrote on > > Date: Wed, 10 Jan 2024 10:01:48 UTC : > > > 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. > > > > I never use atime, always noatime, for UFS. That said, I'd never propose > > changing the long standing defaults for commands and calls. I'd avoid: > > .. Very well said 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 > > .. what Mark said very well removed for brevity ... +1 :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: ZFS problems since recently ?
On Tue, Jan 02, 2024 at 05:51:32PM -0500, Alexander Motin wrote: > Please see/test: https://github.com/openzfs/zfs/pull/15732 . Looks like that has landed in current: commit f552d7adebb13e24f65276a6c4822bffeeac3993 Merge: 13720136fbf a382e21194c Author: Martin Matuska Date: Wed Jan 10 09:07:45 2024 +0100 zfs: merge openzfs/zfs@a382e2119 Notable upstream pull request merges: #15693 a382e2119 Add Gotify notification support to ZED --> #15732 e78aca3b3 Fix livelist assertions for dedup and cloning #15733 7ecaa0758 make zdb_decompress_block check decompression reliably #15735 255741fc9 Improve block sizes checks during cloning Obtained from: OpenZFS OpenZFS commit: a382e21194c1690951d2eee8ebd98bc096f01c83
Re: noatime on ufs2
> Olivier Certner wrote on > Date: Wed, 10 Jan 2024 10:01:48 UTC : > > > 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. > > I never use atime, always noatime, for UFS. That said, I'd never propose > changing the long standing defaults for commands and calls. I'd avoid: .. Very well said 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 .. what Mark said very well removed for brevity ... > Mark Millard > marklmi at yahoo.com -- Rod Grimes rgri...@freebsd.org
Re: noatime on ufs2
Olivier Certner wrote on
Date: Wed, 10 Jan 2024 10:01:48 UTC :
> 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.
I never use atime, always noatime, for UFS. That said, I'd never propose
changing the long standing defaults for commands and calls. 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.)
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.)
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, . . .)
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.)
Note: I've worded the above as if things are always per file system.
Command default that apply across file systems that have the feature
of allowing stored atime are also relevant. But the wording gets messy
if expanded in each relevant place above.
Picking openzfs as an example of documented uniformity . . .
https://openzfs.github.io/openzfs-docs/man/master/7/zfsprops.7.html documents:
QUOTE
atime=on|offControls whether the access time for files is updated when they are
read. Turning this property off avoids producing write traffic when reading
files and can result in significant performance gains, though it might confuse
mailers and other similar utilities. The values on and off are equivalent to
the atime and noatime mount options. The default value is on.
END QUOTE
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.
In my view , the burden to make things work relative such defaults
is not worth the consequences of making a bunch of new distinctions
in a long standing subject area.
===
Mark Millard
marklmi at yahoo.com
Re: noatime on ufs2
On Wed, Jan 10, 2024 at 12:44 PM Lyndon Nerenberg (VE7TFX/VE6BBM) wrote: > > Olivier Certner writes: > > > I've never found any compelling reason in most uses to enable "atime", > > except > > perhaps local mail but as addressed in other answers it is a relic of the > > pa > > st mostly irrelevant today. And its drawbacks are well known and can be > > seri > > ous. > > 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. And in the Usenet days it was common to mount > /var/spool/news noatime, which eliminated a *lot* of meta-info > write traffic. > > 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 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. Just choosing the last message in the thread... I do not have a strong opinion w.r.t. atime, but I do believe that changing the default would be a POLA violation. 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? 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. rick > > --lyndon >
Re: route ipv6 errors on bootup in -current main-n267425-aa1223ac3afc on arm64
> On Jan 9, 2024, at 7:17 AM, void wrote: > > On Tue, Jan 09, 2024 at 12:24:40PM +, void wrote: >> On Tue, Jan 09, 2024 at 10:24:53AM +, void wrote: >>> On Mon, Jan 08, 2024 at 01:07:30PM -0800, Enji Cooper wrote: Was the kernel/utility built with IPv6? If not, that’s a general bug which should be filed (which can be easily checked/avoided using the FEATURES(9) subsystem)… Cheers! -Enji >>> >>> world/kernel was built with WITHOUT_INET6= in /etc/src.conf >>> >>> I made the problem go away with removing WITHOUT_INET6= and rebuilding. >> >> I'll re-add this to try and replicate the problem with the same sources >> (main-n267425-aa1223ac3afc) and if it happens again I'll make a PR for it > > I forgot about this line: > > options INET6 # IPv6 communications protocols > > which, on current/arm64 lives in std.arm64 which gets included by > GENERIC which is included by GENERIC-MMCCAM which is included by > GENERIC-MMCCAM-NODEBUG > > commenting it out and having WITHOUT_INET6= in /etc/src.conf and rebuilding > fixes the problem. Sorry for the noise. It’s not noise; what you found is a valid issue. Please file an issue for this, noting that the kernel was built without INET6 support (that’s the key bit of info for reproing the issue). Thank you! -Enji signature.asc Description: Message signed with OpenPGP
Re: noatime on ufs2
Olivier Certner writes: > I've never found any compelling reason in most uses to enable "atime", except > perhaps local mail but as addressed in other answers it is a relic of the pa > st mostly irrelevant today. And its drawbacks are well known and can be seri > ous. 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. And in the Usenet days it was common to mount /var/spool/news noatime, which eliminated a *lot* of meta-info write traffic. 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 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. --lyndon
Re: noatime on ufs2
On Wed, Jan 10, 2024 at 6:36 PM Olivier Certner wrote: > 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 am reading this interesting discussion and please verify my general understanding: 1. There is a request for change in core OS / FS mechanism of file access time (atime) because of problem with mailing application? 2. Linux change of approach to atime that keeps its value only around last 24h so we should also change it in FreeBSD? 3. "realtime" is the alternative solution to keep atime intact? Why change well known standardized and widely used mechanism that is here for decades? If there is a problem with an application why change core OS/FS with all possible negative consequences and not fix the application? Wouldn't that break POSIX / backward compatiblity? Thanks :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: noatime on ufs2
Hallo Olivier Certner wrote in <2367131.USjQqFH40Q@ravel>: |> 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. Sure. |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 \ It is not true. |the "atime" mechanism addresses these needs poorly. I hate atime. In the past i always turned it off on most partitions, under FreeBSD. If i recall correctly reading FreeBSD documentation (which was my main UNIX learning factor; including the /usr/share stuff that i much admired) ignited that feeling of waste of prescious time (on a Cyrix 166+ with 49 MB RAM and a, uh, maybe 200 or ~250 MB hard disk -- i have forgotten!, i seem to recall about ~300 or 330 MB/sec memory and ~30 MB/sec cached disk performance (Linux), and i am pretty sure about the less than 5 MB/sec otherwise). I think i always used noatime by this time, on FreeBSD (whenever i read out the old IDE disks i hopefully will discover also that). I seem to recall "birth time" did not exist. Now it must be said that today i do not care that much. I do not even have a special partition for /var no more (on the laptop, at least). The memory and that incredible NVME disk are so unbelievable fast that i would not even have dreamed of it. Whereas i still do not truly look at access time myself consciously, i let it happen. (Unless it does not make sense; for example /x/music -- greetings to Kaiserslautern! -- is actually living on multiple disks, and (backup) sticks (well those: actually all), and it is only hm populated on one master (at the moment not NFS shared, but maybe later). That is then cloned everywhere. So. Hm. Ie, twenty and more years ago i surely would have agreed in that i turn(ed) off atime, but today, .. i for myself use relatime here. Also: as a general by-default policy: i do not think so. (But i am only a user.) |With that in mind, developing "relatime" to try to alleviate the shortco\ |mings 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", \ Aha? Which? Today?? Well i mean writing must happen. |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). Not mines. |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") \ Actually it is often distress, as i work on multiple terminals, and the reported "new" mail has often already worked when the message appears. :) |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. Ah ja? |Which need(s) of yours are you trying to address exactly by using "relat\ |ime"? I address that i do not turn off atime. Actually i do not, but get that automatically. But would otherwise. I only set noatime at times. Some utitilities even actively restore access time after they are doing their thing, in a standardized way. |Thanks and regards. I think i want to day that i would not like it if a global policy enforces noatime. Especially since the necessary changes are small, and could even be automatized easily. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
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
On Wed, Jan 10, 2024 at 3:01 AM Olivier Certner wrote: > 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. > Yea... tail -f does it too... But this is a useful way to get your shell to tell you when something has changed. It's a widely used trick (or has been in the past). But it really has nothing to do with atime... Just a clever use of MAIL variable. > 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. > 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. > 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. I'm not sure this is a great notion to have everywhere. I think your analysis needs more inputs. Warner > Regards. > > -- > Olivier Certner
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
Van: Olivier Certner Datum: woensdag, 10 januari 2024 11:01 Aan: Warner Losh CC: freebsd-current@freebsd.org Onderwerp: 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 "And I think this is a sufficiently reasonable conclusion that anyone with the same inputs would conclude the same." This is an interesting type of argument. Ronald.
Re: e179d973 insta-panics in nl_send_one()
On 1/9/24 22:09, Gleb Smirnoff wrote: On Mon, Jan 08, 2024 at 10:40:52AM +0100, Jakob Alvermark wrote: J> > > --- trap 0xc, rip = 0x...f80d97b78, rsp = 0x... J> > > nl_send_one() at nl_send_one+0x18/frame 0xf J> > > nl_send_group() at nl_send_group+0x1bc/frame 0xf... J> > > _nlmsg_flush() at _nlmsg_flush+0x37/frame 0xf... J> > > rtnl_handle_ifevent() + 0xa1 J> > > if_attach_internal + 0x3df J> > > J> > > I have a picture of the full panic if desired... J> > > J> > > -- J> > > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 J> > > p...@freebsd.org | TCP/IP since RFC 956 J> > > FreeBSD committer | BSD since 4.3-tahoe J> > > Never attribute to malice what can adequately be explained by incompetence. J> J> I get the same panic, with kernel and userland both installed. Sorry, that was my failure. Fix pushed and now working on a regression test that would cover Netlink group writers. It works now, thanks! Jakob
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.
