## Lev Serebryakov (l...@freebsd.org):
> net-p2p/monero-cli shows a lot of exceptions on FreeBSD. Monero's
> github [1] says, that it needs "sysctl -w vm.nr_hugepages=1280" on Linux.
> What is FreeBSD equivalent for this Linux' setting?
There is no equivalent setting on FreeBSD (as of yet), a
Hi,
## Konstantin Belousov (kostik...@gmail.com):
> > There is no equivalent setting on FreeBSD (as of yet), and there's
> > no way to explicitely request huge pages (super pages, large pages,
> > whatever you call them) on FreeBSD in the mmap()/shmget() interfaces
> > (as there is in Linux) (the
## FreeBSD Errata Notices (errata-noti...@freebsd.org):
> # fetch https://security.FreeBSD.org/patches/EN-22:11/zfs.patch
Unless I'm totally cross-eyed, this patch is not what has been
committed to releng/13.0
https://cgit.freebsd.org/src/commit/?h=releng/13.0&id=f5be20afc3568876c44269420a5426272
## Mark Johnston (ma...@freebsd.org):
> > The primary difference is that I've never used ccache and
> > did not try to do so here. The "zfs pool is a single disk,
> > no raid, mirror or anything fancy" is accurate, as is the
> > use of ALLOW_MAKE_JOBS= .
That's basically my setup: "single-SSD zpo
## Christoph Moench-Tegeder (c...@burggraben.net):
> ## Mark Johnston (ma...@freebsd.org):
> > Mark or Thomas, if you're able
> > to build a new kernel from the releng/13.0 branch and test it, could you
> > please try this patch?
>
> I'm running that right n
## Christoph Moench-Tegeder (c...@burggraben.net):
> I'm now going back to releng/13.0 and check if that still produces
> the broken files "sometimes" (in the true nature of a concurrency
> issue, the failure is somewhat stochastic).
That was quick: less than 15 minutes
## Eivind Nicolay Evensen (eivi...@terraplane.org):
> <118>/dev/ufs/nyvar-fs: NO WRITE ACCESS
Why "NO WRITE ACCESS"?
> <118>$PRID:$PHOST> fsck -Cy
Do not skip checks in this situation.
Consider the possibility that other parts might have gone bad: cabling,
RAM, CPU... maybe even heat problems?
