-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
The third RC build of the 14.0-RELEASE release cycle is now available.
Installation images are available for:
o 14.0-RC3 amd64 GENERIC
o 14.0-RC3 i386 GENERIC
o 14.0-RC3 powerpc GENERIC
o 14.0-RC3 powerpc64 GENERIC64
o 14.0-RC3 powerpc64le GENERIC6
On 27/10/23 19:09, void wrote:
On Fri, Oct 27, 2023 at 05:38:58PM +0200, Guido Falsi wrote:
If this script is the culprit is easily tested, disable it and see. I
guess you can stay a few days without checking for negative permissions.
I'm unsure how to disable that one script from periodic. b
On 27/10/23 19:09, void wrote:
On Fri, Oct 27, 2023 at 05:38:58PM +0200, Guido Falsi wrote:
If this script is the culprit is easily tested, disable it and see. I
guess you can stay a few days without checking for negative permissions.
I'm unsure how to disable that one script from periodic. b
On Fri, Oct 27, 2023 at 05:38:58PM +0200, Guido Falsi wrote:
Also, $MP is defined in such a way to exclude filesystems that set
"nosuid/noexec". I do happen to have those setup for my ccache
directory so it is skipping that.
With zfs it is especially easy to set these flags, and I think havin
On Fri, Oct 27, 2023 at 05:38:58PM +0200, Guido Falsi wrote:
If this script is the culprit is easily tested, disable it and see. I
guess you can stay a few days without checking for negative
permissions.
I'm unsure how to disable that one script from periodic. but I think
that what you recomm
On Fri, Oct 27, 2023 at 05:23:49PM +0200, Ronald Klop wrote:
Well. You could remove daily_clean_disks_enable="YES" from /etc/periodic.conf.
That saves you the "find". I have never used it before. The default is "off".
Yes, I'll try that, but it's a very recent addition. The periodic daily prob
On 27/10/23 17:24, void wrote:
Hi,
On Fri, Oct 27, 2023 at 11:01:03AM -0400, Paul Mather wrote:
This doesn't affect the periodic daily run (to my knowledge)
# ps x | grep periodic
59319 14 S+ 0:00.00 grep periodic
27376 17 I+ 0:00.00 /bin/sh - /etc/periodic/security/110.neggrp
Hi,
On Fri, Oct 27, 2023 at 11:01:03AM -0400, Paul Mather wrote:
This doesn't affect the periodic daily run (to my knowledge)
# ps x | grep periodic
59319 14 S+ 0:00.00 grep periodic
27376 17 I+ 0:00.00 /bin/sh - /etc/periodic/security/110.neggrpperm
27987 17 I+ 0:00.00
Van: void
Datum: vrijdag, 27 oktober 2023 16:42
Aan: freebsd-sta...@freebsd.org
Onderwerp: Re: periodic daily takes a very long time to run (14-stable)
On Fri, Oct 27, 2023 at 03:34:35PM +0200, Ronald Klop wrote:
>
>What stands out to me is that you do quite a lot of writes on the disk. (I
mig
On 27/10/23 17:07, Guido Falsi wrote:
On 27/10/23 16:42, void wrote:
On Fri, Oct 27, 2023 at 03:34:35PM +0200, Ronald Klop wrote:
So if my observation is right it might be interesting to find out
what is writing.
would ktrace and/or truss be useful? something else? The truss -p
output of th
On 27/10/23 16:42, void wrote:
On Fri, Oct 27, 2023 at 03:34:35PM +0200, Ronald Klop wrote:
So if my observation is right it might be interesting to find out what
is writing.
would ktrace and/or truss be useful? something else? The truss -p output
of the
find PID produces massive amounts of
On Fri, 2023-10-27 at 15:42 +0100, void wrote:
> would ktrace and/or truss be useful? something else? The truss -p
> output of the
> find PID produces massive amounts of output, all like this:
>
> fstatat(AT_FDCWD,"5e70d5f895ccc92af6a7d5226f818b-81464.o",{ mode=-rw-
> r--r--
> ,inode=367004,size
On Fri, Oct 27, 2023 at 03:34:35PM +0200, Ronald Klop wrote:
What stands out to me is that you do quite a lot of writes on the disk. (I
might be mistaken.)
The max. number of IOPS for HDD is around 80 for consumer grade harddisks. I
think this counts for USB connected disks.
https://en.wikiped
Van: void
Datum: vrijdag, 27 oktober 2023 14:51
Aan: freebsd-sta...@freebsd.org
Onderwerp: Re: periodic daily takes a very long time to run (14-stable)
On Fri, Oct 27, 2023 at 01:45:24PM +0200, Ronald Klop wrote:
>Can you run "gstat" or "iostat -x -d 1" to see how busy your disk is? >And how
On Fri, Oct 27, 2023 at 02:46:39PM +0200, Ronald Klop wrote:
Mmm. Your pool has a lot of space left. So that is good.
About gstat / iostat, yes during the daily scan would be nice. The numbers
outside of the daily scan can also help as a reference.
NB: There were talks on the ML about vnode r
On Fri, Oct 27, 2023 at 01:45:24PM +0200, Ronald Klop wrote:
Can you run "gstat" or "iostat -x -d 1" to see how busy your disk is?
And how much bandwidth is uses.
when periodic is *not* running, gstat numbers fluctuate between whats
indicated below and all zeros:
dT: 1.011s w: 1.000s
L(q)
Van: void
Datum: vrijdag, 27 oktober 2023 14:30
Aan: freebsd-sta...@freebsd.org
Onderwerp: Re: periodic daily takes a very long time to run (14-stable)
Hi,
On Fri, Oct 27, 2023 at 01:45:24PM +0200, Ronald Klop wrote:
>Can you run "gstat" or "iostat -x -d 1" to see how busy your disk is? >And
Hi,
On Fri, Oct 27, 2023 at 01:45:24PM +0200, Ronald Klop wrote:
Can you run "gstat" or "iostat -x -d 1" to see how busy your disk is?
And how much bandwidth is uses.
The output of "zpool status", "zpool list" and "zfs list" can also
be interesting.
ZFS is known to become slow when the zpo
Van: void
Datum: vrijdag, 27 oktober 2023 12:15
Aan: freebsd-sta...@freebsd.org
Onderwerp: periodic daily takes a very long time to run (14-stable)
Hello list,
I'm asking this in order to determine whether I've got something misconfigured
or
maybe my expectations need recalibrating, or maybe
Hello list,
I'm asking this in order to determine whether I've got something misconfigured
or
maybe my expectations need recalibrating, or maybe both.
context is rpi4b with 8GB and usb3-connected 1tb zfs hard disk.
/etc/daily.local has been moved out of the way to try to fix the issue.
When pe
20 matches
Mail list logo
