patch that replaces a single linked list with a hash table of lists (mountd.c) for review
Hi, I just put a patch for mountd.c in phabricator as D20270, which replaces the single linked list of structures for exported file systems with a hash table of lists. This is part of what I hope will fix the performance of mountd when reloading the exports file(s) for a server with a lot of exported file systems. Peter Eriksson has reported that his file server with 72000+ exported file systems takes 16sec to reload the exports file(s), which implies that the nfsd threads are suspended for 16sec whenever this happens. If anyone is willing to review this patch, please do so. Thanks, rick ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Inability to build FreeBSD-current amd64
> In general, WITH_CLANG_EXTRAS controls the building of extra tools such > as a disassembler, and tools for working on clang itself such as bug > reporting tools. I don't have a really detailed answer because I've > never enabled the option. I've always perceived it as being something > most people don't need. WITHOUT_CLANG_EXTRAS may cut some time from > your build, but it probably won't cut it in half or anything. >- Ian I am not concerned about the time to build CLANG_EXTRAS so much as the possibility of CLANG_EXTRAS stopping the build. WITH_CLANG_EXTRAS worked back in July-August 2017, but it may have ballooned since then beyond FreeBSD buildability. Tom ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Inability to build FreeBSD-current amd64
On Wed, 2019-05-15 at 23:23 +, Thomas Mueller wrote: > What do most FreeBSD users who rebuild system from source do > regarding WITH_CLANG_EXTRAS in /etc/src.conf ? > > I have WITH_CLANG_EXTRAS=yes in /etc/src.conf and wonder if that > could be screwing my build. > > Build seems to stumble on the llvm stuff, and llvm has really bloated > in recent times. > > But then if I remove WITH_CLANG_EXTRAS, would I face great trouble > with llvm in the ports, where llvm is so critical to the bigger > things including Xorg? > > Would removing WITH_CLANG_EXTRAS also reduce the build time which has > been around 6:45 (hours:minutes) just to fail? > > > Tom > In general, WITH_CLANG_EXTRAS controls the building of extra tools such as a disassembler, and tools for working on clang itself such as bug reporting tools. I don't have a really detailed answer because I've never enabled the option. I've always perceived it as being something most people don't need. WITHOUT_CLANG_EXTRAS may cut some time from your build, but it probably won't cut it in half or anything. -- Ian ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Inability to build FreeBSD-current amd64
What do most FreeBSD users who rebuild system from source do regarding WITH_CLANG_EXTRAS in /etc/src.conf ? I have WITH_CLANG_EXTRAS=yes in /etc/src.conf and wonder if that could be screwing my build. Build seems to stumble on the llvm stuff, and llvm has really bloated in recent times. But then if I remove WITH_CLANG_EXTRAS, would I face great trouble with llvm in the ports, where llvm is so critical to the bigger things including Xorg? Would removing WITH_CLANG_EXTRAS also reduce the build time which has been around 6:45 (hours:minutes) just to fail? Tom ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Updated stream links
FreeBSD Developer Summit Links: Room 1160: https://papers.freebsd.org/2019/bsdcan/streaming_dms1160/ Room 1140: https://papers.freebsd.org/2019/bsdcan/streaming_dms1140/ Room 1130: https://papers.freebsd.org/2019/bsdcan/streaming_dms1130/ ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Inability to build FreeBSD-current amd64
On Wed, 2019-05-15 at 19:26 +, Thomas Mueller wrote: > from tech-lists: > > > What do you do before buildworld? > > > > I'll rm -rf /usr/obj and /var/cache/ccache [1], create them again, > > then in > > /usr/src I'll do this: > > make -j32 cleanworld && make -j32 cleandir && make -j32 clean > > > > before make buildworld. it's probably overkill but it'll for sure > > clean > > away any cruft > > [1] make sure they get deleted without error. I've encountered > > bad_file_descriptor error in ccache dir before and it caused all > > kinds > > of errors when building, which looked like build errors but obv. > > were > > not. > > I did rm -R /usr/obj/* , so everything there was clean as far as I > could see. > > I had no /var/cache/cache . > > I could still try to build current from the old current from August > 2, 2017, or STABLE-12 from the old 11.1-STABLE from July 30, 2017. > > Otherwise I still have stuff to do with NetBSD and Linux toolchains > (OpenWRT, buildroot, crosstool-ng and ptxdist from Pengutronix). > > Is there anything comparable to > https://releng.netbsd.org/cgi-bin/builds.cgi , but for FreeBSD? > > If I see 0 passed, 67 failed for NetBSD-HEAD, I figure I should wait > for a better time. But what about FreeBSD? > > Tom A couple different views on the freebsd build CI... https://ci.freebsd.org/ https://ci.freebsd.org/tinderbox/ -- Ian ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Inability to build FreeBSD-current amd64
from tech-lists: > What do you do before buildworld? > I'll rm -rf /usr/obj and /var/cache/ccache [1], create them again, then in > /usr/src I'll do this: > make -j32 cleanworld && make -j32 cleandir && make -j32 clean > before make buildworld. it's probably overkill but it'll for sure clean > away any cruft > [1] make sure they get deleted without error. I've encountered > bad_file_descriptor error in ccache dir before and it caused all kinds > of errors when building, which looked like build errors but obv. were > not. I did rm -R /usr/obj/* , so everything there was clean as far as I could see. I had no /var/cache/cache . I could still try to build current from the old current from August 2, 2017, or STABLE-12 from the old 11.1-STABLE from July 30, 2017. Otherwise I still have stuff to do with NetBSD and Linux toolchains (OpenWRT, buildroot, crosstool-ng and ptxdist from Pengutronix). Is there anything comparable to https://releng.netbsd.org/cgi-bin/builds.cgi , but for FreeBSD? If I see 0 passed, 67 failed for NetBSD-HEAD, I figure I should wait for a better time. But what about FreeBSD? Tom ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Links
FreeBSD Developer Summit Links: https://papers.freebsd.org/2019/bsdcan/streaming_dms1160/ https://papers.freebsd.org/2019/bsdcan/streaming_dms1140/ http://fengler.ca/test.html ( 1130 link will be added to papers shortly) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
freeBSD Developer Summit - DMS1160 Stream
Hello All, Below is the streaming link for the FreeBSD Developer summit for May 2019 https://papers.freebsd.org/2019/bsdcan/streaming_dms1160/ ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
12-STABLE: poudriere jail installation/updating is failing
Recently an error seem to have spread across our 12-STABLE platforms offering poudriere. Building the binaries for FreeBSD 12-STABLE (recent version r347613) on systems running FreeBSD 12-STABLE (r347613) worked very well before, but now the install process seem to fail on all boxes the very same way; see the error below. Building the binary system runs smooth. The sources are outside /usr/src and setting "env MAKEOBJDIRPREIX=/path/to/source/obj" in /usr/local/etc/poudriere.d/jailname-poudriere.conf reflects that. This source tree is built with the very same src.conf and make.conf files as poudriere would then use for the installation via option poudriere jail -c jail-name -m=/path/to/source/src ... (ZFS is the target filesystem) Any idea what causes this behaviour? On recent CURRENT, building the 12-STABLE jail with the very same revision of 12-STABLE and the very same poudriere config files (those residing in /usr/local/etc/poudriere.d/) works like a charme. Thanks in advance, oh [...] install -N /pool/sources/12-STABLE/src/etc -o root -g wheel -m 444 getopt_long.3.gz /pool/poudriere/jails/12amd64/usr/share/man/man3/ --- realinstall_subdir_libexec --- A failure has been detected in another branch of the parallel make make[5]: stopped in /pool/sources/12-STABLE/src/libexec/hyperv --- realinstall_subdir_lib --- install -N /pool/sources/12-STABLE/src/etc -o root -g wheel -m 444 getsubopt.3.gz /pool/poudriere/jails/12amd64/usr/share/man/man3/ --- realinstall_subdir_libexec --- *** [realinstall_subdir_libexec/hyperv] Error code 2 make[4]: stopped in /pool/sources/12-STABLE/src/libexec 1 error make[4]: stopped in /pool/sources/12-STABLE/src/libexec *** [realinstall_subdir_libexec] Error code 2 make[3]: stopped in /pool/sources/12-STABLE/src --- realinstall_subdir_lib --- install -N /pool/sources/12-STABLE/src/etc -o root -g wheel -m 444 hcreate.3.gz /pool/poudriere/jails/12amd64/usr/share/man/man3/ ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Updated Install Images with ZoL
We're started rolling FreeBSD weekly HEAD images that include the most up to date ZoL ports, selectable at install time: http://pkg.trueos.org/iso/freebsd-pkgbase/ Feel free to give those a shot if you want to test ZoL. As usual, report issues to us via the GitHub issue tracker: https://github.com/zfsonfreebsd/ZoF/issues Thanks to everybody who's been helping us test so far! -- Kris Moore Vice President of Engineering iXsystems, Inc Ph: (408) 943-4100 Ph: (408) 943-4101 The Groundbreaking TrueNAS M-Series - Enterprise Storage & Servers Driven By Open Source ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Inability to build FreeBSD-current amd64
On Wed, May 15, 2019 at 06:46:04AM +, Thomas Mueller wrote: Hi Tom, Are you using any nonstandard build options/modes? Cheers! -Enji I don't think I am using any nonstandard build options/modes. [...] Build didn't even start when I had WITHOUT_MANCOMPRESS on. Trouble occurs before there is any attempt to build the kernel. hi, What do you do before buildworld? I'll rm -rf /usr/obj and /var/cache/ccache [1], create them again, then in /usr/src I'll do this: make -j32 cleanworld && make -j32 cleandir && make -j32 clean before make buildworld. it's probably overkill but it'll for sure clean away any cruft [1] make sure they get deleted without error. I've encountered bad_file_descriptor error in ccache dir before and it caused all kinds of errors when building, which looked like build errors but obv. were not. -- J. signature.asc Description: PGP signature
Re: Inability to build FreeBSD-current amd64
> Hi Tom,
> Are you using any nonstandard build options/modes?
> Cheers!
> -Enji
I don't think I am using any nonstandard build options/modes.
/etc/src.conf is
WITHOUT_SVNLITE=yes
WITHOUT_PORTSNAP=yes
#WITHOUT_MANCOMPRESS=yes
#WITHOUT_DOCCOMPRESS=yes
WITHOUT_SENDMAIL=yes
WITH_CLANG_EXTRAS=yes
WITH_LLD_IS_LD=yes
/etc/make.conf is
PORTSDIR=/BETA1/usr/ports
PACKAGES=/usr/packages
WRKDIR=${.CURDIR}/work11.amd64
#MANCOMPRESSED=no
#MK_MANCOMPRESS="no"
#WITHOUT_MANCOMPRESS=yes
MAKE_JOBS_UNSAFE=yes
FORCE_PKG_REGISTER=yes
# WITH_PKGNG=yes
OPTIONS_SET.mpop=GNUTLS NLS
WITH_BDB_VER=6
WITH_SSP_PORTS=yes
DEFAULT_VERSIONS+= perl5=5.28
DISABLE_VULNERABILITIES=yes
Build didn't even start when I had WITHOUT_MANCOMPRESS on.
Trouble occurs before there is any attempt to build the kernel.
Tom
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: error when updating 13.0-CURRENT i386 poudriere jail to r347606
On 14 May, Don Lewis wrote:
> I just ran into this error when updating my 13.0-CURRENT i386 jail to
> r347606. I did not run into this problem when I upgraded by amd64 jail,
> or when I updated the i386 jail to r347549.
This doesn't seem to be very repeatable. I tried to upgrade the jail
again and it succeeded. There is probably a race that we sometimes
lose.
Both amd64 and i386 upgrades also emitted this error just before
finishing:
--- _ZFSINS_zvol ---
install -N /var/poudriere/jails/13CURRENTi386/usr/src/etc -C -o root -g wheel
-m 555 /var/poudriere/jails/13CURRENTi386/usr/src/libexec/rc/rc.d/zvol
/var/poudriere/jails/13CURRENTi386/etc/rc.d/zvol
awk: can't open file /sys/param.h
source line number 1
>>> Removing old files (only deletes safe to delete libs)
>>> Old files removed
This appears to come from newvers.sh. It looks like ${SYSDIR} is not
set. The error doesn't appear to have any significant ill effects.
> --- lib/libgcc_s__L ---
> sh /var/poudriere/jails/13CURRENTi386/usr/src/tools/install.sh -l rs -o root
> -g wheel -m 755
> /usr/obj/var/poudriere/jails/13CURRENTi386/usr/src/i386.i386/tmp/lib/libgcc_s.so.1
>
> /usr/obj/var/poudriere/jails/13CURRENTi386/usr/src/i386.i386/tmp/usr/lib/libgcc_s.so
> --- lib/libgssapi__L ---
> --- gss_inquire_cred.pico ---
> cc -target i386-unknown-freebsd13.0
> --sysroot=/usr/obj/var/poudriere/jails/13CURRENTi386/usr/src/i386.i386/tmp
> -B/usr/obj/var/poudriere/jails/13CURRENTi386/usr/src/i386.i386/tmp/usr/bin
> -fpic -DPIC -O2 -pipe -g -MD -MF.depend.gss_inquire_cred.pico
> -MTgss_inquire_cred.pico -std=gnu99 -fstack-protector-strong -Wsystem-headers
> -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes
> -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual
> -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align
> -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls
> -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations
> -Wthread-safety -Wno-empty-body -Wno-string-plus-int
> -Wno-unused-const-variable -Qunused-arguments -c
> /var/poudriere/jails/13CURRENTi386/usr/src/lib/libgssapi/gss_inquire_cred.c
> -o gss_inquire_cred.pico
> --- lib/ofed/libibverbs__L ---
> sh /var/poudriere/jails/13CURRENTi386/usr/src/tools/install.sh -o root -g
> wheel -m 444libibverbs.so.1.debug
> /usr/obj/var/poudriere/jails/13CURRENTi386/usr/src/i386.i386/tmp/usr/lib/debug/lib/
> --- lib/libcasper__L ---
> ld: error: unable to find library -lgcc_s
> --- lib/ofed/libibverbs__L ---
> sh /var/poudriere/jails/13CURRENTi386/usr/src/tools/install.sh -l rs -o root
> -g wheel -m 755
> /usr/obj/var/poudriere/jails/13CURRENTi386/usr/src/i386.i386/tmp/lib/libibverbs.so.1
>
> /usr/obj/var/poudriere/jails/13CURRENTi386/usr/src/i386.i386/tmp/usr/lib/libibverbs.so
> --- lib/libcasper__L ---
> ld: error: unable to find library -lgcc_s
> cc: error: linker command failed with exit code 1 (use -v to see invocation)
> *** [libcap_grp.so.1.full] Error code 1
>
> make[6]: stopped in
> /var/poudriere/jails/13CURRENTi386/usr/src/lib/libcasper/services/cap_grp
> 1 error
>
> make[6]: stopped in
> /var/poudriere/jails/13CURRENTi386/usr/src/lib/libcasper/services/cap_grp
> *** [all_subdir_lib/libcasper/services/cap_grp] Error code 2
>
> make[5]: stopped in
> /var/poudriere/jails/13CURRENTi386/usr/src/lib/libcasper/services
> 1 error
>
> make[5]: stopped in
> /var/poudriere/jails/13CURRENTi386/usr/src/lib/libcasper/services
> *** [all_subdir_lib/libcasper/services] Error code 2
>
> make[4]: stopped in /var/poudriere/jails/13CURRENTi386/usr/src/lib/libcasper
> 1 error
>
> make[4]: stopped in /var/poudriere/jails/13CURRENTi386/usr/src/lib/libcasper
> --- lib/libgcc_s__L ---
> A failure has been detected in another branch of the parallel make
>
> make[4]: stopped in /var/poudriere/jails/13CURRENTi386/usr/src/lib/libgcc_s
> *** [lib/libgcc_s__L] Error code 2
>
> make[3]: stopped in /var/poudriere/jails/13CURRENTi386/usr/src
> --- lib/libcasper__L ---
> *** [lib/libcasper__L] Error code 2
>
> make[3]: stopped in /var/poudriere/jails/13CURRENTi386/usr/src
> --- lib/ofed/libibverbs__L ---
> A failure has been detected in another branch of the parallel make
>
> make[4]: stopped in
> /var/poudriere/jails/13CURRENTi386/usr/src/lib/ofed/libibverbs
> *** [lib/ofed/libibverbs__L] Error code 2
>
> make[3]: stopped in /var/poudriere/jails/13CURRENTi386/usr/src
> --- cddl/lib/libzfs_core__L ---
> A failure has been detected in another branch of the parallel make
>
> make[4]: stopped in
> /var/poudriere/jails/13CURRENTi386/usr/src/cddl/lib/libzfs_core
> *** [cddl/lib/libzfs_core__L] Error code 2
>
> make[3]: stopped in /var/poudriere/jails/13CURRENTi386/usr/src
> --- lib/ncurses/ncursesw__L ---
> A failure has been detected in another branch of the parallel make
>
> make[4]: stopped in
> /var/poudriere/jails/13CURRENTi386/usr/src/lib/ncurses/ncursesw
> *** [lib/ncurses/ncursesw__L]
