On Thu, Apr 11, 2024 at 06:15:14PM +0200, Otto Moerbeek wrote: > On Thu, Apr 11, 2024 at 05:29:14PM +0200, Otto Moerbeek wrote: > > > On Thu, Apr 11, 2024 at 05:20:24PM +0200, Otto Moerbeek wrote: > > > > > On Thu, Apr 11, 2024 at 05:08:01PM +0200, Federico Giannici wrote: > > > > > > > On 4/11/24 16:15, Claudio Jeker wrote: > > > > > On Thu, Apr 11, 2024 at 03:36:29PM +0200, Federico Giannici wrote: > > > > > > On 4/11/24 14:12, Nick Holland wrote: > > > > > > > On 4/11/24 05:47, Federico Giannici wrote: > > > > > > > > We have a server with A LOT of files in some directories (an > > > > > > > > email > > > > > > > > server in maildir format). > > > > > > > > > > > > > > > > Since we upgraded from OpenBSD amd64 7.3 to 7.5 (passing > > > > > > > > through 7.4) it > > > > > > > > became very very very slow to access these large directories! > > > > > > > ,,, > > > > > > > You may be being bitten by the removal of softdeps (soft updates) > > > > > > > in 7.4 more than the availability of a knob to twist. This was a > > > > > > > huge hit for some things -- I had one backup job go from a couple > > > > > > > hours to eight or so hours. However, it turned out that increase > > > > > > > in time has not inconvenienced me at all, and some random lockups > > > > > > > related to softdeps have gone away. Overall, win for me (the > > > > > > > fscks after a lockup took hours, too, not to mention all the time > > > > > > > and effort spent replacing part after part assuming it was a HW > > > > > > > issue). > > > > > > > > > > > > > > As I understand it...there were known (known unknown?) bugs in the > > > > > > > softdep code, the code was ugly, and it made it difficult to > > > > > > > actually improve the code. > > > > > > > > > > > > No, we knew that softdeps were being deprecated and we removed from > > > > > > everywhere some time ago. It must be something else. > > > > > > > > > > > > Anyway, it's strange that dirhash parameters has being changed and > > > > > > removed > > > > > > without any mention... > > > > > > > > > > It was not (this is on -current amd64): > > > > > vfs.ffs.dirhash_dirsize=2560 > > > > > vfs.ffs.dirhash_maxmem=5242880 > > > > > vfs.ffs.dirhash_mem=4832510 > > > > > > > > > > Are you sure your kernel and userland are in sync? > > > > > > > > Well, I followed the prescribed procedure (I'm using OpenBSD since... > > > > about > > > > 20 years). > > > > > > > > In EVERY machine upgraded to 7.5 now I have something like this: > > > > > > > > Elrond:/home/giannici$ sysctl vfs.ffs > > > > > > > > > > > > > > > > vfs.ffs.dirhash_maxmem=2560 > > > > vfs.ffs.dirhash_mem=5242880 > > > > > > > > Elrond:/home/giannici$ uname -a > > > > > > > > > > > > > > > > OpenBSD Elrond.neomedia.it 7.5 GENERIC.MP#82 amd64 > > > > > > > > > > > > So, I'm the only one? > > > > > > > > Thanks. > > > > > > > > > > I suspect > > > > > > In > > > https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/ufs/ffs/ffs_exatern.h.diff?r1=1.45&r2=1.46&f=h > > > > > > The max_softdeps entry in ffs_extern.h should have been replace by a > > > { 0, 0 } > > > > > > instead of being removed. > > > > > > -Otto > > > > > > > Yes, that fixes it for me: > > > > $ sysctl vfs.ffs > > vfs.ffs.dirhash_dirsize=2560 > > vfs.ffs.dirhash_maxmem=5242880 > > vfs.ffs.dirhash_mem=767359 > > $ > > > > to elaborate a bit: the vfs.ffs.dirhash_maxmem enty was actually > showing the value of the vfs.ffs.dirhash_dirsize entry. Trying to set the > vfs.ffs.dirhash_maxmem entry would result into setting the > vfs.ffs.dirhash_dirsize entry, which effectively disables dirhash if > yon set it to a high value. > > It remains a mystery why Claudio is seeing the correct values... you'd > almost think he uses an old sysctl binary, or his tree is out of sync > somehow. >
My bad I ran the command on a system that was still running 7.4 without realizing that. -- :wq Claudio
