bhyve regression ?
Going from a kernel from Dec 21st to today, my bhyve image no longer
starts up. Is this possibly related to the mfc 356471 ?
/boot/kernel/kernel text=0x948ee3 data=0x13d9b8+0x463b10
syms=[0x8+0xef220+0x8+0x10ec23]
/boot/entropy size=0x1000
Booting...
/tmp/bhyve.e6GT9mY 61: [0001] ProcessorId : FF
Error
6313 - Invalid field label detected ^ (found "ProcessorId" expected
"Processor ID")
/tmp/bhyve.e6GT9mY 65: [0001] Interrupt : 01
Error 6313 - Invalid field label detected ^ (found "Interrupt"
expected "Interrupt Input LINT")
Assertion failed: (error == 0), function main, file
/usr/src/usr.sbin/bhyve/bhyverun.c, line 1190.
Abort trap (core dumped)
Line 1190 is
if (acpi) {
error = acpi_build(ctx, guest_ncpus);
assert(error == 0);
}
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: bhyve regression ?
On 1/8/2020 10:15 AM, mike tancsa wrote:
> Going from a kernel from Dec 21st to today, my bhyve image no longer
> starts up. Is this possibly related to the mfc 356471 ?
>
>
OK, confirmed. Doing a svnlite update -r356469, to just before the ACPI
MFC allows be to start up my bhyve image.
---Mike
> /boot/kernel/kernel text=0x948ee3 data=0x13d9b8+0x463b10
> syms=[0x8+0xef220+0x8+0x10ec23]
> /boot/entropy size=0x1000
> Booting...
> /tmp/bhyve.e6GT9mY 61: [0001] ProcessorId : FF
> Error
> 6313 - Invalid field label detected ^ (found "ProcessorId" expected
> "Processor ID")
>
>
>
>
> /tmp/bhyve.e6GT9mY 65: [0001] Interrupt : 01
> Error 6313 - Invalid field label detected ^ (found "Interrupt"
> expected "Interrupt Input LINT")
>
>
>
> Assertion failed: (error == 0), function main, file
> /usr/src/usr.sbin/bhyve/bhyverun.c, line 1190.
>
>
>
> Abort trap (core dumped)
>
>
> Line 1190 is
> if (acpi) {
> error = acpi_build(ctx, guest_ncpus);
> assert(error == 0);
> }
>
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: nfs lockd errors after NetApp software upgrade.
top posting NetAPP reply: … Here you can see transaction ID (0x5e15f77a) being used over port 886 and the NFS server successfully responds. 44806952020-01-08 12:20:54 132.65.116.111 132.65.60.56 NLM 0x5e15f77a (1578497914) 886 V4 UNLOCK Call (Reply In 4480696) FH:0x54b075a0 svid:13629 pos:0-0 44806962020-01-08 12:20:54 132.65.60.56 132.65.116.111 NLM 0x5e15f77a (1578497914) 4045 V4 UNLOCK Reply (Call In 4480695) Here you see that 2 minutes later the client uses the same transaction ID (0x5e15f77a) and the same port again, but the file handle is different, so the client is unlocking a different file. 45911362020-01-08 12:22:54 132.65.116.111 132.65.60.56 NLM 0x5e15f77a (1578497914) 886 [RPC retransmission of #4480695]V4 UNLOCK Call (Reply In 4480696) FH:0xb14b75a8 svid:13629 pos:0-0 45925882020-01-08 12:22:57 132.65.116.111 132.65.60.56 NLM 0x5e15f77a (1578497914) 886 [RPC retransmission of #4480695]V4 UNLOCK Call (Reply In 4480696) FH:0xb14b75a8 svid:13629 pos:0-0 45988622020-01-08 12:23:03 132.65.116.111 132.65.60.56 NLM 0x5e15f77a (1578497914) 886 [RPC retransmission of #4480695]V4 UNLOCK Call (Reply In 4480696) FH:0xb14b75a8 svid:13629 pos:0-0 46088712020-01-08 12:23:21 132.65.116.111 132.65.60.56 NLM 0x5e15f77a (1578497914) 886 [RPC retransmission of #4480695]V4 UNLOCK Call (Reply In 4480696) FH:0xb14b75a8 svid:13629 pos:0-0 46359842020-01-08 12:23:59 132.65.116.111 132.65.60.56 NLM 0x5e15f77a (1578497914) 886 [RPC retransmission of #4480695]V4 UNLOCK Call (Reply In 4480696) FH:0xb14b75a8 svid:13629 pos:0-0 transaction ID reuse is also seen for a number of other transaction IDs starting at the same time. Withing ONTAP 9.3 we have changed the way our Replay-Cache tracks requests by including a checksum of the RPC request. Both in in this and earlier releases ONTAP would cache the call in frame 4480695, but starintg in 9.3 we then cache the checksum as part of that. When the client sends the request in frame 4591136 it uses the same transaction ID (0x5e15f77a) and same port again. Here the problem is that we already hold a checksum in cache for the “same transaction” … this seems to be happening after the client did not receive the response and re-transmits the request. danny > On 24 Dec 2019, at 5:02, Rick Macklem wrote: > > Richard P Mackerras wrote: >> Hi, >> >> We had some bully type workloads emerge when we moved a lot of block >> storage from old XIV to new all flash 3PAR. I wonder if your IMAP issue >> might have emerged just because suddenly there was the opportunity with all >> flash. QOS is good on 9.x ONTAP. If anyone says it’s not then they last >> looked on 8.x. So I suggest you QOS the IMAP workload. >> >> Nobody should be using UDP with NFS unless they have a very specific set >> of circumstances. TCP was a real step forward. > Well, I can't argue with this, considering I did the first working > implementation > of NFS over TCP. It was actually Mike Karels that suggested I try doing so, > There's a paper in a very old Usenix Conference Proceedings, but it is so old > that it isn't on the Usenix web page (around 1988 in Denver, if I recall). I > don't > even have a copy myself, although I was the author. > > Now, having said that, I must note that the Network Lock Manager (NLM) and > Network Status Monitor (NSM) were not NFS. They were separate stateful > protocols (poorly designed imho) that Sun never published. > > NFS as Sun designed it (NFSv2 and NFSv3) were "stateless server" protocols, > so that they could work reliably without server crash recovery. > However, the NLM was inherently stateful, since it was dealing with file > locks. > > So, you can't really lump the NLM with NFS (and you should avoid use of the > NLM over any transport imho). > > NFSv4 tackled the difficult problem of having a "stateful server" and crash > recovery, > which resulted in a much more complex protocol (compare the size of RFC-1813 > vs RFC-5661 to get some idea of this). > > rick > > Cheers > > Richard > ___ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > ___ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ f
Re: bhyve regression ?
On 20. 1. 8., mike tancsa wrote: > On 1/8/2020 10:15 AM, mike tancsa wrote: >> Going from a kernel from Dec 21st to today, my bhyve image no longer >> starts up. Is this possibly related to the mfc 356471 ? >> >> > OK, confirmed. Doing a svnlite update -r356469, to just before the ACPI > MFC allows be to start up my bhyve image. I forgot to merge r354056. Please update your source (r356500) and try again. Sorry for the breakage. Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: svn commit: r356465 - in stable/12: . contrib/llvm-project/clang/include/clang/CodeGen contrib/llvm-project/clang/lib/Basic/Targets contrib/llvm-project/clang/lib/CodeGen contrib/llvm-project/clan
On 1/7/2020 3:01 PM, Dimitry Andric wrote: > Author: dim > Date: Tue Jan 7 20:01:59 2020 > New Revision: 356465 > URL: https://svnweb.freebsd.org/changeset/base/356465 > > Log: > MFC r356004: > > Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp > 9.0.1 final release c1a0a213378a458fbea1a5c77b315c7dce08fd05. > > Release notes for llvm, clang, lld and libc++ 9.0.1 will become > available here: Hi, Is the buildworld a 2 step process to install everything ? I rebuilt world post import, did installkernel, installworld and then went to rebuild again, yet in the output, it still shows make[1]: "/usr/src/Makefile.inc1" line 341: SYSTEM_COMPILER: Determined that CC=cc matches the source tree. Not bootstrapping a cross-compiler. make[1]: "/usr/src/Makefile.inc1" line 348: SYSTEM_LINKER: libclang will be built for bootstrapping a cross-linker. Did libclang somehow not get installed or is the check not working for the version ? I am at r356502 root@asrock-ryzen7a:/usr/src # sleep 20;time make -j 16 buildworld > /var/log/build.out ; time make -j16 buildkernel > /var/log/build.out.k [Creating objdir /usr/obj/usr/src/amd64.amd64...] 20805.460u 1075.767s 26:02.05 1400.8% 58220+3452k 650321+3431159io 222076pf+0w 1487.734u 147.997s 1:45.14 1555.7% 52726+3205k 195595+3387101io 70456pf+0w root@asrock-ryzen7a:/usr/src # Just tried again. installkernel/world and reboot, yet still get SYSTEM_LINKER: libclang will be built for bootstrapping a cross-linker. ---Mike ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: bhyve regression ? (resolved with r356500)
On 1/8/2020 12:33 PM, Jung-uk Kim wrote: > On 20. 1. 8., mike tancsa wrote: >> On 1/8/2020 10:15 AM, mike tancsa wrote: >>> Going from a kernel from Dec 21st to today, my bhyve image no longer >>> starts up. Is this possibly related to the mfc 356471 ? >>> >>> >> OK, confirmed. Doing a svnlite update -r356469, to just before the ACPI >> MFC allows be to start up my bhyve image. > I forgot to merge r354056. Please update your source (r356500) and try > again. Thanks very much for the quick fix. This does indeed fix the issue for me! ---Mike ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: svn commit: r356465 - in stable/12: . contrib/llvm-project/clang/include/clang/CodeGen contrib/llvm-project/clang/lib/Basic/Targets contrib/llvm-project/clang/lib/CodeGen contrib/llvm-project/clan
On 1/8/2020 1:08 PM, Ian Lepore wrote: > I am at r356502 >> root@asrock-ryzen7a:/usr/src # sleep 20;time make -j 16 buildworld > >> /var/log/build.out ; time make -j16 buildkernel > /var/log/build.out.k >> [Creating objdir /usr/obj/usr/src/amd64.amd64...] >> 20805.460u 1075.767s 26:02.05 1400.8% 58220+3452k 650321+3431159io >> 222076pf+0w >> 1487.734u 147.997s 1:45.14 1555.7% 52726+3205k 195595+3387101io >> 70456pf+0w >> root@asrock-ryzen7a:/usr/src # >> >> Just tried again. installkernel/world and reboot, yet still get >> SYSTEM_LINKER: libclang will be built for bootstrapping a cross-linker. >> >> >> ---Mike >> > What's the output of "make test-system-compiler"? That will display > all the variables used to make the decisions on what to (re)build. Just installed again and rebooted root@asrock-ryzen7a:/usr/src # svnlite status --show-updates Status against revision: 356505 root@asrock-ryzen7a:/usr/src # root@asrock-ryzen7a:/usr/src # make test-system-compiler USING_SYSTEM_COMPILER = yes MK_SYSTEM_COMPILER = yes MK_CROSS_COMPILER = yes MK_CLANG_BOOTSTRAP = no MK_GCC_BOOTSTRAP = no WANT_COMPILER_TYPE = clang WANT_COMPILER_VERSION = 90001 WANT_COMPILER_VERSION_FILE = lib/clang/include/clang/Basic/Version.inc WANT_COMPILER_FREEBSD_VERSION = 1200021 WANT_COMPILER_FREEBSD_VERSION_FILE = lib/clang/freebsd_cc_version.h CC = cc COMPILER_TYPE = clang COMPILER_FEATURES = c++11 c++14 c++17 retpoline COMPILER_VERSION = 90001 COMPILER_FREEBSD_VERSION = 1200021 XCC = cc X_COMPILER_TYPE = clang X_COMPILER_FEATURES = c++11 c++14 c++17 retpoline X_COMPILER_VERSION = 90001 X_COMPILER_FREEBSD_VERSION = 1200021 root@asrock-ryzen7a:/usr/src # make test-system-linker USING_SYSTEM_LINKER = no MK_SYSTEM_LINKER = yes MK_LLD_BOOTSTRAP = yes MK_BINUTILS_BOOTSTRAP = yes WANT_LINKER_TYPE = lld WANT_LINKER_VERSION = 90001 WANT_LINKER_VERSION_FILE = lib/clang/include/lld/Common/Version.inc WANT_LINKER_FREEBSD_VERSION = WANT_LINKER_FREEBSD_VERSION_FILE = lib/clang/include/lld/Common/Version.inc LD = ld LINKER_TYPE = lld LINKER_FEATURES = build-id ifunc filter retpoline LINKER_VERSION = 90001 LINKER_FREEBSD_VERSION = c1a0a213378a458fbea1a5c77b315c7dce08fd05-1200010 XLD = ld X_LINKER_TYPE = lld X_LINKER_FEATURES = build-id ifunc filter retpoline X_LINKER_VERSION = 90001 X_LINKER_FREEBSD_VERSION = c1a0a213378a458fbea1a5c77b315c7dce08fd05-1200010 root@asrock-ryzen7a:/usr/src # ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: svn commit: r356465 - in stable/12: . contrib/llvm-project/clang/include/clang/CodeGen contrib/llvm-project/clang/lib/Basic/Targets contrib/llvm-project/clang/lib/CodeGen contrib/llvm-project/clan
On 1/8/2020 1:14 PM, mike tancsa wrote: > On 1/8/2020 1:08 PM, Ian Lepore wrote: >> I am at r356502 >>> root@asrock-ryzen7a:/usr/src # sleep 20;time make -j 16 buildworld > >>> /var/log/build.out ; time make -j16 buildkernel > /var/log/build.out.k >>> [Creating objdir /usr/obj/usr/src/amd64.amd64...] >>> 20805.460u 1075.767s 26:02.05 1400.8% 58220+3452k 650321+3431159io >>> 222076pf+0w >>> 1487.734u 147.997s 1:45.14 1555.7% 52726+3205k 195595+3387101io >>> 70456pf+0w >>> root@asrock-ryzen7a:/usr/src # >>> >>> Just tried again. installkernel/world and reboot, yet still get >>> SYSTEM_LINKER: libclang will be built for bootstrapping a cross-linker. >>> >>> >>> ---Mike >>> >> What's the output of "make test-system-compiler"? That will display >> all the variables used to make the decisions on what to (re)build. > Just installed again and rebooted > > root@asrock-ryzen7a:/usr/src # svnlite status --show-updates > Status against revision: 356505 > root@asrock-ryzen7a:/usr/src # > > root@asrock-ryzen7a:/usr/src # make test-system-compiler > USING_SYSTEM_COMPILER = yes > MK_SYSTEM_COMPILER = yes > MK_CROSS_COMPILER = yes > MK_CLANG_BOOTSTRAP = no > MK_GCC_BOOTSTRAP = no > WANT_COMPILER_TYPE = clang > WANT_COMPILER_VERSION = 90001 > WANT_COMPILER_VERSION_FILE = > lib/clang/include/clang/Basic/Version.inc > WANT_COMPILER_FREEBSD_VERSION = 1200021 > WANT_COMPILER_FREEBSD_VERSION_FILE = lib/clang/freebsd_cc_version.h > CC = cc > COMPILER_TYPE = clang > COMPILER_FEATURES = c++11 c++14 c++17 retpoline > COMPILER_VERSION = 90001 > COMPILER_FREEBSD_VERSION = 1200021 > XCC = cc > X_COMPILER_TYPE = clang > X_COMPILER_FEATURES = c++11 c++14 c++17 retpoline > X_COMPILER_VERSION = 90001 > X_COMPILER_FREEBSD_VERSION = 1200021 > root@asrock-ryzen7a:/usr/src # make test-system-linker > USING_SYSTEM_LINKER = no > MK_SYSTEM_LINKER = yes > MK_LLD_BOOTSTRAP = yes > MK_BINUTILS_BOOTSTRAP = yes > WANT_LINKER_TYPE = lld > WANT_LINKER_VERSION = 90001 > WANT_LINKER_VERSION_FILE = > lib/clang/include/lld/Common/Version.inc > WANT_LINKER_FREEBSD_VERSION = > WANT_LINKER_FREEBSD_VERSION_FILE = > lib/clang/include/lld/Common/Version.inc > LD = ld > LINKER_TYPE = lld > LINKER_FEATURES = build-id ifunc filter retpoline > LINKER_VERSION = 90001 > LINKER_FREEBSD_VERSION = > c1a0a213378a458fbea1a5c77b315c7dce08fd05-1200010 > XLD = ld > X_LINKER_TYPE = lld > X_LINKER_FEATURES = build-id ifunc filter retpoline > X_LINKER_VERSION = 90001 > X_LINKER_FREEBSD_VERSION = > c1a0a213378a458fbea1a5c77b315c7dce08fd05-1200010 > root@asrock-ryzen7a:/usr/src # > I also did make delete-old and make delete-old-libs, but no difference. make test-system-compiler and make test-system-linker give the same results. Also just tried blowing away /usr/obj and the same deal. The system linker needs to be rebuilt each time make[1]: "/usr/src/Makefile.inc1" line 341: SYSTEM_COMPILER: Determined that CC=cc matches the source tree. Not bootstrapping a cross-compiler. make[1]: "/usr/src/Makefile.inc1" line 348: SYSTEM_LINKER: libclang will be built for bootstrapping a cross-linker. ---Mike ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: svn commit: r356465 - in stable/12: . contrib/llvm-project/clang/include/clang/CodeGen contrib/llvm-project/clang/lib/Basic/Targets contrib/llvm-project/clang/lib/CodeGen contrib/llvm-project/clan
On 8 Jan 2020, at 19:37, mike tancsa wrote: > > On 1/8/2020 1:14 PM, mike tancsa wrote: >> On 1/8/2020 1:08 PM, Ian Lepore wrote: >>> I am at r356502 root@asrock-ryzen7a:/usr/src # sleep 20;time make -j 16 buildworld > /var/log/build.out ; time make -j16 buildkernel > /var/log/build.out.k [Creating objdir /usr/obj/usr/src/amd64.amd64...] 20805.460u 1075.767s 26:02.05 1400.8% 58220+3452k 650321+3431159io 222076pf+0w 1487.734u 147.997s 1:45.14 1555.7% 52726+3205k 195595+3387101io 70456pf+0w root@asrock-ryzen7a:/usr/src # Just tried again. installkernel/world and reboot, yet still get SYSTEM_LINKER: libclang will be built for bootstrapping a cross-linker. ---Mike >>> What's the output of "make test-system-compiler"? That will display >>> all the variables used to make the decisions on what to (re)build. >> Just installed again and rebooted >> >> root@asrock-ryzen7a:/usr/src # svnlite status --show-updates >> Status against revision: 356505 >> root@asrock-ryzen7a:/usr/src # >> >> root@asrock-ryzen7a:/usr/src # make test-system-compiler >> USING_SYSTEM_COMPILER = yes >> MK_SYSTEM_COMPILER = yes >> MK_CROSS_COMPILER = yes >> MK_CLANG_BOOTSTRAP = no >> MK_GCC_BOOTSTRAP = no >> WANT_COMPILER_TYPE = clang >> WANT_COMPILER_VERSION = 90001 >> WANT_COMPILER_VERSION_FILE = >> lib/clang/include/clang/Basic/Version.inc >> WANT_COMPILER_FREEBSD_VERSION = 1200021 >> WANT_COMPILER_FREEBSD_VERSION_FILE = lib/clang/freebsd_cc_version.h >> CC = cc >> COMPILER_TYPE = clang >> COMPILER_FEATURES = c++11 c++14 c++17 retpoline >> COMPILER_VERSION = 90001 >> COMPILER_FREEBSD_VERSION = 1200021 >> XCC= cc >> X_COMPILER_TYPE= clang >> X_COMPILER_FEATURES= c++11 c++14 c++17 retpoline >> X_COMPILER_VERSION = 90001 >> X_COMPILER_FREEBSD_VERSION = 1200021 >> root@asrock-ryzen7a:/usr/src # make test-system-linker >> USING_SYSTEM_LINKER= no >> MK_SYSTEM_LINKER = yes >> MK_LLD_BOOTSTRAP = yes >> MK_BINUTILS_BOOTSTRAP = yes >> WANT_LINKER_TYPE = lld >> WANT_LINKER_VERSION= 90001 >> WANT_LINKER_VERSION_FILE = >> lib/clang/include/lld/Common/Version.inc >> WANT_LINKER_FREEBSD_VERSION= >> WANT_LINKER_FREEBSD_VERSION_FILE = >> lib/clang/include/lld/Common/Version.inc >> LD = ld >> LINKER_TYPE= lld >> LINKER_FEATURES= build-id ifunc filter retpoline >> LINKER_VERSION = 90001 >> LINKER_FREEBSD_VERSION = >> c1a0a213378a458fbea1a5c77b315c7dce08fd05-1200010 >> XLD= ld >> X_LINKER_TYPE = lld >> X_LINKER_FEATURES = build-id ifunc filter retpoline >> X_LINKER_VERSION = 90001 >> X_LINKER_FREEBSD_VERSION = >> c1a0a213378a458fbea1a5c77b315c7dce08fd05-1200010 >> root@asrock-ryzen7a:/usr/src # >> > I also did make delete-old and make delete-old-libs, but no difference. > make test-system-compiler and make test-system-linker give the same > results. > > Also just tried blowing away /usr/obj and the same deal. The system > linker needs to be rebuilt each time > > make[1]: "/usr/src/Makefile.inc1" line 341: SYSTEM_COMPILER: Determined > that CC=cc matches the source tree. Not bootstrapping a cross-compiler. > make[1]: "/usr/src/Makefile.inc1" line 348: SYSTEM_LINKER: libclang will > be built for bootstrapping a cross-linker. Hm, so it thinks the compiler is new enough, but not the linker? This might be due to the recent change of the upstream Subversion revision into a Git coommit hash, e.g. lld used to print: LLD 9.0.0 (FreeBSD 372316-135) (compatible with GNU linkers) but now it prints: LLD 9.0.1 (FreeBSD c1a0a213378a458fbea1a5c77b315c7dce08fd05-136) (compatible with GNU linkers) The first number or hash is the upstream revision or commit, the second number is "our" monotonically increasing version number. If we make changes that require re-bootstrapping the linker, we bump that second number. I think something in the MK_SYSTEM_LINKER logic may have fallen over due to the change in this output. Ed, any ideas? Note I didn't see any reports about this in head, but it could also be a problem there. -Dimitry signature.asc Description: Message signed with OpenPGP
Re: two questions about autofs on FBSD
On 0103T1602, Lee Damon wrote: > I am (reluctantly) replacing am-utils (amd) with autofs. To do this I > need to replace a lot of functionality that I've had embedded for a very > long time and which my users absolutely rely on. I have two (so far) > questions that I need to solve before I can proceed with this process. > > Question 1 - One of those features is the ability to use a symlink > instead of a NFS mount. For a simplistic example: > > /homes/accountname -> /net/server/home/accountname > > On Linux this is a : entry in /etc/auto.homes: > accountname :/net/server/home/accountname > > but when I test it on FBSD 11-3 I get: > automountd[1784]: "mount -t nfs -o automounted,retrycnt=1 > /net/[redacted]/vol/home/[redacted] /homes/[redacted]/", pid 1785, > terminated with exit status 1 > > Which sure looks like it is trying to NFS mount the local filesystem, > which clearly won't work. > > I use this functionality all over the place including linking into AFS > space and making smart decisions of which subdirectory to present, so I > can't just turn all of the links into NFS mounts. > > I found a bug report against the 10.1 version of autofs asking for the > linking functionality but it was closed with no comment. I'm not finding > any other documentation that references how to do a link. I'm afraid linking isn't supported. I've always considered it an optimization that made sense back when NFS could have significant overhead and nowadays just wasn't worth it. One thing you could try is to use nullfs(5) instead of NFS for this specific case. I no longer remember all the details, but simply adding '-t nullfs' to the map entry above should work. > The media mount seems to be done via a special script instead of just a > link. So, I have to ask, is this something that can be done? How do I do it? Media mounts are handled by executable maps, aka special maps; there's nothing media-specific in autofs itself, apart from the /etc/autofs/special_media shell script. Now that you mention it, there is a /etc/autofs/include_nis_nullfs special map which does the nullfs symlink, although it's to be used with NIS. Might be useful if adding "-t nullfs" in a static map file isn't enough. > Question 2 - How do I get automount to reload a map if a filesystem is > already mounted? It looks like issuing the "automount" command with no > flags should get it to reload maps but it seems to be ignoring any > changes to a map if that map has anything active. > > 99% of my map updates are to add a new filesystem to an existing map and > I need all of the hosts to pick up the changes the next time CM runs. On > Linux "systemctl reload autofs" does it but "service automount reload" > doesn't exist, and as I said, "automount" ignores map changes for active > maps. I'm _certain_ I'm missing something simple and obvious here, I > can't believe there's no way to reload an active map. > > Any information related to either question is much appreciated. Executing "automount" will refresh top-level mounts (ie all the filesystems of type "autofs"); running "automount -c" will flush cached maps referenced from /etc/auto_master. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: svn commit: r356465 - in stable/12: . contrib/llvm-project/clang/include/clang/CodeGen contrib/llvm-project/clang/lib/Basic/Targets contrib/llvm-project/clang/lib/CodeGen contrib/llvm-project/clan
On 8 Jan 2020, at 22:00, Dimitry Andric wrote: > > On 8 Jan 2020, at 19:37, mike tancsa wrote: >> >> On 1/8/2020 1:14 PM, mike tancsa wrote: >>> On 1/8/2020 1:08 PM, Ian Lepore wrote: I am at r356502 > root@asrock-ryzen7a:/usr/src # sleep 20;time make -j 16 buildworld > > /var/log/build.out ; time make -j16 buildkernel > /var/log/build.out.k > [Creating objdir /usr/obj/usr/src/amd64.amd64...] > 20805.460u 1075.767s 26:02.05 1400.8% 58220+3452k 650321+3431159io > 222076pf+0w > 1487.734u 147.997s 1:45.14 1555.7% 52726+3205k 195595+3387101io > 70456pf+0w > root@asrock-ryzen7a:/usr/src # > > Just tried again. installkernel/world and reboot, yet still get > SYSTEM_LINKER: libclang will be built for bootstrapping a cross-linker. ... > I think something in the MK_SYSTEM_LINKER logic may have fallen over due > to the change in this output. Ed, any ideas? > > Note I didn't see any reports about this in head, but it could also be > a problem there. I just noticed this was fixed in head by Bryan Drewery in r354859: URL: https://svnweb.freebsd.org/changeset/base/354859 Log: WITH_SYSTEM_LINKER: Fix rebuilding lld every time. This is due to LLD_REVISION_STRING being renamed to LLD_REVISION in r351442 and the value being moved to another location in r351965. `make test-system-linker` can be used to see the values being used here. Reported by: ler I have just MFC'd this to stable/12, in r356518. Thanks for the report! -Dimitry signature.asc Description: Message signed with OpenPGP
Re: two questions about autofs on FBSD
On 1/8/20 13:09 , Edward Tomasz Napierała wrote: > I'm afraid linking isn't supported. I've always considered it > an optimization that made sense back when NFS could have significant > overhead and nowadays just wasn't worth it. > > One thing you could try is to use nullfs(5) instead of NFS for this > specific case. I no longer remember all the details, but simply adding > '-t nullfs' to the map entry above should work. Part of the problem for me is that I need to use the same map files on multiple OSs. :/path/to/thing works in Linux but doesn't work in FBSD. I haven't had a chance to try -t nullfs yet but I'm going to bet it doesn't work in Linux. Then there's omnios ... > Executing "automount" will refresh top-level mounts (ie all the filesystems > of type "autofs"); running "automount -c" will flush cached maps referenced > from /etc/auto_master. Thanks. I'll try that next time this project comes around on the guitar (which is to say, probably Friday). nomad ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: nfs lockd errors after NetApp software upgrade.
Switch to using TCP should avoid the DRC crap. (Most systems except FreeBSD only do DRC for UDP.) I assume that by "transaction ID", they are referring to the XID in the RPC header. (I'll take a look at how it is maintained for UDP in the krpc. Btw, although their code expecting it to change for a different RPC isn't surprising, the xid's behaviour is "underspecified" in the Sun RPC RFC.) rick From: Daniel Braniss Sent: Wednesday, January 8, 2020 12:08 PM To: Rick Macklem Cc: Richard P Mackerras; Adam McDougall; freebsd-stable@freebsd.org Subject: Re: nfs lockd errors after NetApp software upgrade. top posting NetAPP reply: … Here you can see transaction ID (0x5e15f77a) being used over port 886 and the NFS server successfully responds. 44806952020-01-08 12:20:54 132.65.116.111 132.65.60.56 NLM 0x5e15f77a (1578497914) 886 V4 UNLOCK Call (Reply In 4480696) FH:0x54b075a0 svid:13629 pos:0-0 44806962020-01-08 12:20:54 132.65.60.56 132.65.116.111 NLM 0x5e15f77a (1578497914) 4045 V4 UNLOCK Reply (Call In 4480695) Here you see that 2 minutes later the client uses the same transaction ID (0x5e15f77a) and the same port again, but the file handle is different, so the client is unlocking a different file. 45911362020-01-08 12:22:54 132.65.116.111 132.65.60.56 NLM 0x5e15f77a (1578497914) 886 [RPC retransmission of #4480695]V4 UNLOCK Call (Reply In 4480696) FH:0xb14b75a8 svid:13629 pos:0-0 45925882020-01-08 12:22:57 132.65.116.111 132.65.60.56 NLM 0x5e15f77a (1578497914) 886 [RPC retransmission of #4480695]V4 UNLOCK Call (Reply In 4480696) FH:0xb14b75a8 svid:13629 pos:0-0 45988622020-01-08 12:23:03 132.65.116.111 132.65.60.56 NLM 0x5e15f77a (1578497914) 886 [RPC retransmission of #4480695]V4 UNLOCK Call (Reply In 4480696) FH:0xb14b75a8 svid:13629 pos:0-0 46088712020-01-08 12:23:21 132.65.116.111 132.65.60.56 NLM 0x5e15f77a (1578497914) 886 [RPC retransmission of #4480695]V4 UNLOCK Call (Reply In 4480696) FH:0xb14b75a8 svid:13629 pos:0-0 46359842020-01-08 12:23:59 132.65.116.111 132.65.60.56 NLM 0x5e15f77a (1578497914) 886 [RPC retransmission of #4480695]V4 UNLOCK Call (Reply In 4480696) FH:0xb14b75a8 svid:13629 pos:0-0 transaction ID reuse is also seen for a number of other transaction IDs starting at the same time. Withing ONTAP 9.3 we have changed the way our Replay-Cache tracks requests by including a checksum of the RPC request. Both in in this and earlier releases ONTAP would cache the call in frame 4480695, but starintg in 9.3 we then cache the checksum as part of that. When the client sends the request in frame 4591136 it uses the same transaction ID (0x5e15f77a) and same port again. Here the problem is that we already hold a checksum in cache for the “same transaction” … this seems to be happening after the client did not receive the response and re-transmits the request. danny On 24 Dec 2019, at 5:02, Rick Macklem mailto:rmack...@uoguelph.ca>> wrote: Richard P Mackerras wrote: Hi, We had some bully type workloads emerge when we moved a lot of block storage from old XIV to new all flash 3PAR. I wonder if your IMAP issue might have emerged just because suddenly there was the opportunity with all flash. QOS is good on 9.x ONTAP. If anyone says it’s not then they last looked on 8.x. So I suggest you QOS the IMAP workload. Nobody should be using UDP with NFS unless they have a very specific set of circumstances. TCP was a real step forward. Well, I can't argue with this, considering I did the first working implementation of NFS over TCP. It was actually Mike Karels that suggested I try doing so, There's a paper in a very old Usenix Conference Proceedings, but it is so old that it isn't on the Usenix web page (around 1988 in Denver, if I recall). I don't even have a copy myself, although I was the author. Now, having said that, I must note that the Network Lock Manager (NLM) and Network Status Monitor (NSM) were not NFS. They were separate stateful protocols (poorly designed imho) that Sun never published. NFS as Sun designed it (NFSv2 and NFSv3) were "stateless server" protocols, so that they could work reliably without server crash recovery. However, the NLM was inherently stateful, since it was dealing with file locks. So, you can't really lump the NLM with NFS (and you should avoid use of the NLM over any transport imho). NFSv4 tackled the difficult problem of having a "stateful server" and crash recovery, which resulted in a much more complex protocol (compare the si
Re: nfs lockd errors after NetApp software upgrade.
I hope you don't mind the top post, but...
Here's a snippet of code from the krpc (I wasn't the author):
if (stat == RPC_TIMEDOUT) {
/*
* Check for async send misfeature for NLM
* protocol.
*/
if ((rc->rc_timeout.tv_sec == 0
&& rc->rc_timeout.tv_usec == 0)
|| (rc->rc_timeout.tv_sec == -1
&& utimeout.tv_sec == 0
&& utimeout.tv_usec == 0)) {
CLNT_RELEASE(client);
break;
}
}
This causes the xid to be reinitialized when a timeout occurs.
The reinitialization uses __RPC_GETXID(&now) and it does an exclusive or of
pid ^ time.sec ^ time.usec
so it shouldn't end up the same anyhow.
(Normally this initialization only occurs once, but because of the above, it
could happen multiple times for the NLM. What does "async misfeature"
mean? I have no idea.
If by "transaction id" they are referring to the svid in the lock RPC message,
I have no idea if it should be unique for lock ops on different files.
What does the spec. say? No idea, since there is no such thing.
Anyhow, using TCP will avoid the DRC and whatever the Netapp filer
thinks w.r.t. the uniqueness of this field.
rick
From: Daniel Braniss
Sent: Wednesday, January 8, 2020 12:08 PM
To: Rick Macklem
Cc: Richard P Mackerras; Adam McDougall; freebsd-stable@freebsd.org
Subject: Re: nfs lockd errors after NetApp software upgrade.
top posting NetAPP reply:
…
Here you can see transaction ID (0x5e15f77a) being used over port 886 and the
NFS server successfully responds.
44806952020-01-08 12:20:54 132.65.116.111
132.65.60.56 NLM 0x5e15f77a (1578497914) 886
V4 UNLOCK Call (Reply In 4480696) FH:0x54b075a0 svid:13629 pos:0-0
44806962020-01-08 12:20:54 132.65.60.56
132.65.116.111 NLM 0x5e15f77a (1578497914) 4045
V4 UNLOCK Reply (Call In 4480695)
Here you see that 2 minutes later the client uses the same transaction ID
(0x5e15f77a) and the same port again, but the file handle is different, so the
client is unlocking a different file.
45911362020-01-08 12:22:54 132.65.116.111
132.65.60.56 NLM 0x5e15f77a (1578497914) 886
[RPC retransmission of #4480695]V4 UNLOCK Call (Reply In 4480696)
FH:0xb14b75a8 svid:13629 pos:0-0
45925882020-01-08 12:22:57 132.65.116.111
132.65.60.56 NLM 0x5e15f77a (1578497914) 886
[RPC retransmission of #4480695]V4 UNLOCK Call (Reply In 4480696)
FH:0xb14b75a8 svid:13629 pos:0-0
45988622020-01-08 12:23:03 132.65.116.111
132.65.60.56 NLM 0x5e15f77a (1578497914) 886
[RPC retransmission of #4480695]V4 UNLOCK Call (Reply In 4480696)
FH:0xb14b75a8 svid:13629 pos:0-0
46088712020-01-08 12:23:21 132.65.116.111
132.65.60.56 NLM 0x5e15f77a (1578497914) 886
[RPC retransmission of #4480695]V4 UNLOCK Call (Reply In 4480696)
FH:0xb14b75a8 svid:13629 pos:0-0
46359842020-01-08 12:23:59 132.65.116.111
132.65.60.56 NLM 0x5e15f77a (1578497914) 886
[RPC retransmission of #4480695]V4 UNLOCK Call (Reply In 4480696)
FH:0xb14b75a8 svid:13629 pos:0-0
transaction ID reuse is also seen for a number of other transaction IDs
starting at the same time.
Withing ONTAP 9.3 we have changed the way our Replay-Cache tracks requests by
including a checksum of the RPC request. Both in in this and earlier releases
ONTAP would cache the call in frame 4480695, but starintg in 9.3 we then cache
the checksum as part of that.
When the client sends the request in frame 4591136 it uses the same transaction
ID (0x5e15f77a) and same port again. Here the problem is that we already hold a
checksum in cache for the “same transaction”
…
this seems to be happening after the client did not receive the response and
re-transmits the request.
danny
On 24 Dec 2019, at 5:02, Rick Macklem
mailto:rmack...@uoguelph.ca>> wrote:
Richard P Mackerras wrote:
Hi,
We had some bully type workloads emerge when we moved a lot of block
storage from old XIV to new all flash 3PAR. I wonder if your IMAP issue
might have emerged just because suddenly there was the opportunity with all
flash. QOS is good on 9.x ONTAP. If anyone says it’s not then they last
looked on 8.x. So I suggest you QOS the IMAP workload.
Nobody should be using UDP with NFS unless they have a very specific set
of circumstances. TCP was a real step forward.
Well, I ca
Re: nfs lockd errors after NetApp software upgrade.
The attached patch changes the xid to be a global for all "connections" for the krpc UDP client. You could try it if you'd like. It passed a trivial test, but I don't know why there is that "misfeature" comment means, so I don't know if this breaks that. I can't think of why "xid" would have been per-connection (especially since a connection is a questionable concept for UDP), except that this might have originated in a userland library and carried into the kernel during porting. rick From: Daniel Braniss Sent: Wednesday, January 8, 2020 12:08 PM To: Rick Macklem Cc: Richard P Mackerras; Adam McDougall; freebsd-stable@freebsd.org Subject: Re: nfs lockd errors after NetApp software upgrade. top posting NetAPP reply: … Here you can see transaction ID (0x5e15f77a) being used over port 886 and the NFS server successfully responds. 44806952020-01-08 12:20:54 132.65.116.111 132.65.60.56 NLM 0x5e15f77a (1578497914) 886 V4 UNLOCK Call (Reply In 4480696) FH:0x54b075a0 svid:13629 pos:0-0 44806962020-01-08 12:20:54 132.65.60.56 132.65.116.111 NLM 0x5e15f77a (1578497914) 4045 V4 UNLOCK Reply (Call In 4480695) Here you see that 2 minutes later the client uses the same transaction ID (0x5e15f77a) and the same port again, but the file handle is different, so the client is unlocking a different file. 45911362020-01-08 12:22:54 132.65.116.111 132.65.60.56 NLM 0x5e15f77a (1578497914) 886 [RPC retransmission of #4480695]V4 UNLOCK Call (Reply In 4480696) FH:0xb14b75a8 svid:13629 pos:0-0 45925882020-01-08 12:22:57 132.65.116.111 132.65.60.56 NLM 0x5e15f77a (1578497914) 886 [RPC retransmission of #4480695]V4 UNLOCK Call (Reply In 4480696) FH:0xb14b75a8 svid:13629 pos:0-0 45988622020-01-08 12:23:03 132.65.116.111 132.65.60.56 NLM 0x5e15f77a (1578497914) 886 [RPC retransmission of #4480695]V4 UNLOCK Call (Reply In 4480696) FH:0xb14b75a8 svid:13629 pos:0-0 46088712020-01-08 12:23:21 132.65.116.111 132.65.60.56 NLM 0x5e15f77a (1578497914) 886 [RPC retransmission of #4480695]V4 UNLOCK Call (Reply In 4480696) FH:0xb14b75a8 svid:13629 pos:0-0 46359842020-01-08 12:23:59 132.65.116.111 132.65.60.56 NLM 0x5e15f77a (1578497914) 886 [RPC retransmission of #4480695]V4 UNLOCK Call (Reply In 4480696) FH:0xb14b75a8 svid:13629 pos:0-0 transaction ID reuse is also seen for a number of other transaction IDs starting at the same time. Withing ONTAP 9.3 we have changed the way our Replay-Cache tracks requests by including a checksum of the RPC request. Both in in this and earlier releases ONTAP would cache the call in frame 4480695, but starintg in 9.3 we then cache the checksum as part of that. When the client sends the request in frame 4591136 it uses the same transaction ID (0x5e15f77a) and same port again. Here the problem is that we already hold a checksum in cache for the “same transaction” … this seems to be happening after the client did not receive the response and re-transmits the request. danny On 24 Dec 2019, at 5:02, Rick Macklem mailto:rmack...@uoguelph.ca>> wrote: Richard P Mackerras wrote: Hi, We had some bully type workloads emerge when we moved a lot of block storage from old XIV to new all flash 3PAR. I wonder if your IMAP issue might have emerged just because suddenly there was the opportunity with all flash. QOS is good on 9.x ONTAP. If anyone says it’s not then they last looked on 8.x. So I suggest you QOS the IMAP workload. Nobody should be using UDP with NFS unless they have a very specific set of circumstances. TCP was a real step forward. Well, I can't argue with this, considering I did the first working implementation of NFS over TCP. It was actually Mike Karels that suggested I try doing so, There's a paper in a very old Usenix Conference Proceedings, but it is so old that it isn't on the Usenix web page (around 1988 in Denver, if I recall). I don't even have a copy myself, although I was the author. Now, having said that, I must note that the Network Lock Manager (NLM) and Network Status Monitor (NSM) were not NFS. They were separate stateful protocols (poorly designed imho) that Sun never published. NFS as Sun designed it (NFSv2 and NFSv3) were "stateless server" protocols, so that they could work reliably without server crash recovery. However, the NLM was inherently stateful, since it was dealing with file locks. So, you can't really lump the NLM with NFS (and you should avoid use of the NLM over any transport imho). NFSv4 tackled the difficult problem of having a "stateful s
