Re: NFS performance with 10GBase-T

On Sun, Feb 25, 2024 at 4:57 PM Mark Saad wrote: > > H > > On Sun, Feb 25, 2024 at 6:51 PM Rick Macklem wrote: >> >> On Sun, Feb 25, 2024 at 1:21 AM wrote: >> > >> > CAUTION: This email originated from outside of the University of Guelph. >> >

Re: NFS performance with 10GBase-T

On Sun, Feb 25, 2024 at 1:21 AM wrote: > > CAUTION: This email originated from outside of the University of Guelph. Do > not click links or open attachments unless you recognize the sender and know > the content is safe. If in doubt, forward suspicious emails to > ith...@uoguelph.ca. > > > >

Re: Increasing TCP TSO size support

On Fri, Feb 2, 2024 at 6:20 PM Drew Gallatin wrote: > > > > On Fri, Feb 2, 2024, at 9:05 PM, Rick Macklem wrote: > > > But the page size is only 4K on most platforms. So while an M_EXTPGS mbuf > > can hold 5 pages (..from memory, too lazy to do the math right now) and

Re: Increasing TCP TSO size support

On Fri, Feb 2, 2024 at 4:48 PM Drew Gallatin wrote: > > > > On Fri, Feb 2, 2024, at 6:13 PM, Rick Macklem wrote: > > A factor here is the if_hw_tsomaxsegcount limit. For example, a 1Mbyte NFS > write request > or read reply will result in a 514 element mbuf chain. Eac

Re: Increasing TCP TSO size support

On Fri, Feb 2, 2024 at 1:21 AM Scheffenegger, Richard wrote: > > Hi, > > We have run a test for a RPC workload with 1MB IO sizes, and collected the > tcp_default_output() len(gth) during the first pass in the output loop. > > In such a scenario, where the application frequently introduces small

Re: NFSv4 on MacOS Monterey

Adonis Peralta wrote: > Rick Macklem wrote: > > Yep, as noted above, they aren't supported and will not work. FreeBSD uses > > the Linux style extended > > attribute model, not the resource fork/subfile one that Mac OSX and Solaris > > use. > > > &g

Re: NFSv4 on MacOS Monterey

Rick Macklem wrote: > Adonis Peralta wrote: [stuff snipped] > > OS: FreeBSD 13.1 [more stuff snipped] > > RESULTS > > > > What I see when I connect via finder is the following: > > > > 1. I am able to read/write to the shares since /etc/exports contain

Re: make NFSv3 default now on diskless

John-Mark Gurney wrote: > Rick Macklem wrote this message on Thu, Jun 02, 2022 at 14:44 +: > > John-Mark Gurney wrote: > > > I just booted FreeBSD-current diskless, using NFS root, and I ended > > > up having issues because by default, NFS root is only v2

Re: NFSv4 on MacOS Monterey

Adonis Peralta wrote: > I have some NFSv4 (sec=sys) shares on FreeBSD 13.1 which I'm trying to > connect correctly with MacOS 12.4 > Monterey. > I got the basics down but don't think I have permissions and extended > attributes working correctly. Well, here are a few comments. Note that I

Re: make NFSv3 default now on diskless

Rick Macklem wrote: > John-Mark Gurney wrote: > > I just booted FreeBSD-current diskless, using NFS root, and I ended > > up having issues because by default, NFS root is only v2. > > > > One of things that happened was disk space available was listed as > >

Re: make NFSv3 default now on diskless

John-Mark Gurney wrote: > I just booted FreeBSD-current diskless, using NFS root, and I ended > up having issues because by default, NFS root is only v2. > > One of things that happened was disk space available was listed as > -138G, or -144830429K. I assume this is because the server is

Can net interfaces efficiently transmit data in extpg mbufs?

Hi, The current NFS code knows how to optionally put the large RPC messages (read/readdir replies and write requests) in extpg mbufs instead of mbuf clusters. This was done so that the data did not need to be copied when the KTLS (which requires extpg mbufs) is being used. However, I am

Re: Chelsio cards, jumbo frames, memory fragmentation and performance in FreeBSD 13.x?

Ryan Stone wrote: > > Set it to 4k and move on. I'm not aware of any efforts in the VM > layer or network stack to make >PAGE_SIZE clusters usable in practical > situations. Honestly, at this point I wish that we'd just kill them > entirely. I feel about the same. However, I'm guessing that

Re: RFC: NFS trunking (multiple TCP connections for a mount

Gerrit Kuehn wrote: >On Fri, 27 Aug 2021 14:55:52 +0000 >Rick Macklem wrote: > >> >https://reviews.freebsd.org/R10:1e0a518d65488caafff89a4ecba9cfb2be233379 >> > >> >I guess I'm still too unfamiliar with the new code repository. How >> >would I fin

Re: RFC: NFS trunking (multiple TCP connections for a mount

Gerrit Kuehn wrote: >Rick Macklem wrote: > >> >In case anyone is interested in testing and/or reviewing the patch, >> >it is at https://reviews.freebsd.org/D30970. > >> The phabricator patch has been updated. Please test/review/comment. > >Sorry for picki

Re: RFC: NFS trunking (multiple TCP connections for a mount

Rick Macklem wrote: >In case anyone is interested in testing and/or reviewing the patch, >it is at https://reviews.freebsd.org/D30970. > >Only lightly tested at this point. > >The NFS mount option is "nconnect=", where 2<= N <= 16, >same as Linux. (I haven

Re: RFC: NFS trunking (multiple TCP connections for a mount

your input, rick From: Peter Eriksson Sent: Tuesday, June 29, 2021 5:11 AM To: Rick Macklem Cc: freebsd-net Subject: Re: RFC: NFS trunking (multiple TCP connections for a mount CAUTION: This email originated from outside of the University of Guelph. Do

Re: RFC: NFS trunking (multiple TCP connections for a mount

n is worth implementing. Thanks for your input, rick From: Peter Eriksson Sent: Tuesday, June 29, 2021 5:11 AM To: Rick Macklem Cc: freebsd-net Subject: Re: RFC: NFS trunking (multiple TCP connections for a mount CAUTION: This email originated fr

RFC: NFS trunking (multiple TCP connections for a mount

The Linux NFS client now has a mount option "nconnect", which specifies that multiple TCP connections be created for an NFS mount, where RPCs are done on the connections, in a round robin fashion. (Alternating between the two TCP connections for the case of nconnect=2.) The Linux man page says:

Re: Client Networking Issues / NIC Lab

Kyle Evans wrote: >On Fri, Apr 23, 2021 at 12:22 AM Kevin Bowling >wrote: >> >> Greetings, >> >> [... snip ...] >> >> Tehuti Networks seems to have gone out of business. Probably not >> worth worrying about. >> > >That's unfortunate. I had a box of their 10G NICs and I got them to >put a driver

Re: NFS Mount Hangs

I should be able to test D69290 in about a week. Note that I will not be able to tell if it fixes otis@'s hung Linux client problem. rick From: Scheffenegger, Richard Sent: Sunday, April 11, 2021 12:54 PM To: tue...@freebsd.org; Rick Macklem Cc: Youssef

Re: NFS Mount Hangs

tue...@freebsd.org wrote: >Rick wrote: [stuff snipped] >>> With r367492 you don't get the upcall with the same error state? Or you >>> don't get an error on a write() call, when there should be one? > If Send-Q is 0 when the network is partitioned, after healing, the krpc sees > no activity on >

Re: NFS Mount Hangs

Scheffenegger, Richard wrote: >>Rick wrote: >> Hi Rick, >> >>> Well, I have some good news and some bad news (the bad is mostly for >>> Richard). >>> >>> The only message logged is: >>> tcpflags 0x4; tcp_do_segment: Timestamp missing, segment processed >>> normally >>> Btw, I did get one

Re: NFS Mount Hangs

tue...@freebsd.org wrote: >> On 10. Apr 2021, at 02:44, Rick Macklem wrote: >> >> tue...@freebsd.org wrote: >>>> On 6. Apr 2021, at 01:24, Rick Macklem wrote: >>>> >>>> tue...@freebsd.org wrote: >>>> [stuff snipped] >>&g

Re: NFS Mount Hangs

tue...@freebsd.org wrote: >> On 6. Apr 2021, at 01:24, Rick Macklem wrote: >> >> tue...@freebsd.org wrote: >> [stuff snipped] >>> OK. What is the FreeBSD version you are using? >> main Dec. 23, 2020. >> >>> >>> It seems that the TCP

Re: NFS Mount Hangs

e kernel RPC. If it happens again, it would be nice to at least monitor "netstat -a" on the servers, to see what state the connections are in. >Not really helpful but that it self-healed after a (long) while is interesting >I think… What's that saying "patience is a virtue". I

Re: NFS Mount Hangs

reestablishment of the connection >> did not work... > It is looking like it takes either a non-empty send-q or a > soshutdown(..SHUT_WR) to get the FreeBSD socket > out of established, where it just ignores the RSTs and > SYN packets. > > Thanks for looking at it, rick >

Re: NFS Mount Hangs

tue...@freebsd.org wrote: >> On 4. Apr 2021, at 22:28, Rick Macklem wrote: >> >> Oops, yes the packet capture is on freefall (forgot to mention that;-). >> You should be able to: >> % fetch https://people.freebsd.org/~rmacklem/linuxtofreenfs.pcap >> &

Re: NFS Mount Hangs

2671667056], length 48: NFS reply xid > 697039765 reply ok 44 getattr ERROR: unk 10063 > > This error 10063 after the partition heals is also "bad news". It indicates > the Session > (which is supposed to maintain "exactly once" RPC semantics is broken). I'll

Re: NFS Mount Hangs

ain This was taken at the Linux end. I have FreeBSD end too, although I don't think it tells you anything more. Have fun with it, rick From: tue...@freebsd.org Sent: Sunday, April 4, 2021 12:41 PM To: Rick Macklem Cc: Scheffenegger, Richard; Youssef GHORBAL; freebsd-

Re: NFS Mount Hangs

s correct behaviour or if the RST should be ack'd sooner? I could also see this becoming a "forever" TCP battle for other versions of Linux client. rick From: Scheffenegger, Richard Sent: Sunday, April 4, 2021 7:50 AM To: Rick Macklem; tue...@freebsd.org Cc: Yousse

Re: NFS Mount Hangs

Updating my post slightly... tue...@freebsd.org wrote: >> On 2. Apr 2021, at 02:07, Rick Macklem wrote: >> >> I hope you don't mind a top post... >> I've been testing network partitioning between the only Linux client >> I have (5.2 kernel) and a FreeBSD server wi

Re: NFS Mount Hangs

tue...@freebsd.org wrote: >> On 2. Apr 2021, at 02:07, Rick Macklem wrote: >> >> I hope you don't mind a top post... >> I've been testing network partitioning between the only Linux client >> I have (5.2 kernel) and a FreeBSD server with the xprtdied.patch >&

Re: NFS Mount Hangs

27, 2021 6:57 PM To: Jason Breitman Cc: Rick Macklem; freebsd-net@freebsd.org Subject: Re: NFS Mount Hangs CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If in doubt, forw

Re: NFS Mount Hangs

I am going to create a FreeBSD PR for this, so that this does not get forgotten. If anyone has a problem with me cutting/pasting their comments in this thread into the PR, please email me soon. (If I don't hear from you soon, I'll assume you are ok with it.) Same goes for a post to

Re: NFS Mount Hangs

Youssef GHORBAL wrote: >Hi Jason, > >> On 17 Mar 2021, at 18:17, Jason Breitman >> wrote: >> >> Please review the details below and let me know if there is a setting that I >> should apply to my FreeBSD NFS Server or if there is a bug fix that I can >> apply to resolve my issue. >> I shared

Re: NFS Mount Hangs

Scheffenegger, Richard wrote: >Sorry, I though this was a problem on stable/13. > >This is only in HEAD, stable/13 and 13.0 - never MFC'd to stable/12 or >backported to >12.1 > >> I did some reshuffling of socket-upcalls recently in the TCP stack, to >> prevent some race conditions with our

Re: NFS Mount Hangs

what the thread is up to. Good luck with it, rick Thanks. Jason Breitman On Mar 19, 2021, at 11:58 AM, Rick Macklem wrote: Michael Tuexen wrote: >> On 18. Mar 2021, at 21:55, Rick Macklem wrote: >> >> Michael Tuexen wrote: >>>> On 18. Mar 2021, at 13:42,

Re: NFS Mount Hangs

Michael Tuexen wrote: >> On 18. Mar 2021, at 21:55, Rick Macklem wrote: >> >> Michael Tuexen wrote: >>>> On 18. Mar 2021, at 13:42, Scheffenegger, Richard >>>> wrote: >>>> >>>>>> Output from the NFS Client when the issu

Re: NFS Mount Hangs

Michael Tuexen wrote: >> On 18. Mar 2021, at 13:42, Scheffenegger, Richard >> wrote: >> Output from the NFS Client when the issue occurs # netstat -an | grep NFS.Server.IP.X tcp0 0 NFS.Client.IP.X:46896 NFS.Server.IP.X:2049 FIN_WAIT2 >>> I'm no TCP

Re: NFS Mount Hangs

Alan Somers wrote: [stuff snipped] >Is the 128K limit related to MAXPHYS? If so, it should be greater in 13.0. For the client, yes. For the server, no. For the server, it is just a compile time constant NFS_SRVMAXIO. It's mainly related to the fact that I haven't gotten around to testing larger

Re: NFS Mount Hangs

Jason Breitman wrote: >Please review the details below and let me know if there is a setting that I >should >apply to my FreeBSD NFS Server or if there is a bug fix that I can >apply to resolve my >issue. >I shared this information with the linux-nfs mailing list and they believe the >issue is

Re: nfsd doesn't register with rpcbind

Ondra Knezour wrote: [stuff snipped] >So my questions are: >1. Why my nfsd doesn't register with rpcbind? >2. Is this registration somewhat optional at least for NFSv4? NFSv4 does not use rpcbind. This is generally considered a feature and not a bug. --> nfsd will register with rpcbind only if

Re: TFO for NFS

and on... I do hope that NFS over TLS allows more use of NFS across the Internet, so performance work related to NFS running on WAN/Internet connections would be a great thing to do. (I'm not conversant with the current TCP stack, so I'm not the guy to tackle this.) rick Richard Scheffenegger --

Re: nfsuserd in a jail

Norman Gray wrote: >There is a 'fixed' bug [1] referring to problems that nfsuserd has, when >working in a jail. > >This appears to explain a problem I'm having getting nfsuserd running >within a jail on a 12.0-RELEASE machine (which I'm aware is now EoL, >since we're beyond 12.1-RELEASE + 3

Re: nfsuserd in a jail

Norman Gray wrote: >There is a 'fixed' bug [1] referring to problems that nfsuserd has, when >working in a jail. > >This appears to explain a problem I'm having getting nfsuserd running >within a jail on a 12.0-RELEASE machine (which I'm aware is now EoL, >since we're beyond 12.1-RELEASE + 3

Re: how to fix an interesting issue with mountd?

rds sequentially instead of the text >file). I think what you have, which puts the info in a db file and then SIGHUPs mountd is a good start. Again, if someone else can get this into ZFS, I can put the bits in mountd. Thanks for posting this, rick ps: Do you happen to know how long a reload of

Re: how to fix an interesting issue with mountd?

Rodney Grimes wrote: >> Hi, >> >> I'm posting this one to freebsd-net@ since it seems vaguely similar >> to a network congestion problem and thought that network types >> might have some ideas w.r.t. fixing it? >> >> PR#246597 - Reports a problem (which if I understand it is) where a sighup >>

Re: how to fix an interesting issue with mountd?

Updated slightly from the previous post... Hi, I'm posting this one to freebsd-net@ since it seems vaguely similar to a network congestion problem and thought that network types might have some ideas w.r.t. fixing it? PR#246597 - Reports a problem (which if I understand it is) where a sighup

how to fix an interesting issue with mountd?

Hi, I'm posting this one to freebsd-net@ since it seems vaguely similar to a network congestion problem and thought that network types might have some ideas w.r.t. fixing it? PR#246597 - Reports a problem (which if I understand it is) where a sighup is posted to mountd and then another sighup

use of m_copym() for ext_pgs mbufs?

Hi, Since I am just figuring out ext_pgs mbufs, I thought I'd check... It looks like using m_copym() on a list of ext_pgs mbufs is ok only if it copying the entire list (ie. m_copym(m, 0, M_COPYALL,..)). Is that correct? Thanks, rick ___

Re: Does sosend() need CURVNET_SET/CURVNET_RESTORE?

Hans Petter Selasky wrote: >On 2020-02-02 22:22, Rick Macklem wrote: >> Hi, >> >> The current krpc code calls sosend() and soreceive() without any >> CURVNET_SET()/CURVNET_RESTORE() wrapped around them. >> >> When I recently used sosend_generic(), it p

Re: Does sosend() need CURVNET_SET/CURVNET_RESTORE?

Kristof Provost wrote: >On 2 Feb 2020, at 13:22, Rick Macklem wrote: >> The current krpc code calls sosend() and soreceive() without any >> CURVNET_SET()/CURVNET_RESTORE() wrapped around them. >> >sosend() and soreceive() do the CURVENT_SET()/CURVNET_RESTORE() dance >fo

Does sosend() need CURVNET_SET/CURVNET_RESTORE?

Hi, The current krpc code calls sosend() and soreceive() without any CURVNET_SET()/CURVNET_RESTORE() wrapped around them. When I recently used sosend_generic(), it panic'd without them. Do they need to be added around sosend()/soreceive()? I'll admit to knowing nothing about vnet. Thanks,

NFS performance depends on low latency reception of small TCP segments

Hi, I have seen recent discussion related to NET_EPOCH. This is way out of my expertise, but... NFS traffic is basically bi-directional small messages. If a change increases the latency of reception of a small message (TCP segment) which is not followed by further TCP segments in the same

Re: Two or more exports files, is it feasible?

My reply didn't seem to go through, so here it is again... You can list pathnames for exports files after the other arguments to mountd. See man mountd. If you want this to happen at boot, I think you can put a line like: mountd_flags="-r -S /etc/exports1 /etc/exports2" in your /etc/rc.conf

Re: Umounting an NFS-mounted share after connection is lost?

Alan Somers wrote: >On Mon, Oct 28, 2019 at 8:53 PM Thomas Mueller >wrote: > >> How do you umount a file system that has been mounted with mount_nfs when >> the connection is lost? >> >> Server can crash, cable modem could quit and not hold power, or a change >> in cable modem or router could

Re: Two or more exports files, is it feasible?

Thomas Mueller wrote: >Is is possible to have two or more /etc/exports files, using different names >of >course? You can provide a list of pathnames after the other command line arguments. See "man mountd". >One possible scenario is having one exports file for NFS 4 and one for NFS3, >for

Re: Re[2]: Network anomalies after update from 11.2 STABLE to 12.1 STABLE

Btw, I once ran into a situation where "smart networking" was injecting RSTs into a TCP stream. The packet captures at the client and server machines were identical, except for the RSTs and the problem went away when I connected the two machines with a cable, bypassing the network. Might be worth

Re: rpc.statd already ipv6 clean?

Bjoern A. Zeeb wrote: >On 27 Sep 2019, at 21:52, Rick Macklem wrote: > >> Mihir Luthra wrote: >>> Hi Rick, >>> Rick wrote: >>>> Although I'll admit it isn't something I am particularily fond of, >>>> FreeBSD likes >>>> utilities

Re: rpc.statd already ipv6 clean?

Mihir Luthra wrote: >Hi Rick, >Rick wrote: >>Although I'll admit it isn't something I am particularily fond of, FreeBSD >>likes >>utilities to build/work with only one of ipv4/ipv6. >>To do this, "#ifdef INET" and "#ifdef INET6" is applied to the code and the >>Makefile is tweaked to define one

Re: rpc.statd already ipv6 clean?

Mihir Luthra wrote: >Hiroki Sato wrote: >> >> >> I think you should learn TI-RPC API first. The nettype specifies a >> class of transport protocol, not address family. >> >> Thanks, I did some more research on TI-RPC today. >In `statd.c` what I see is in `create_service()`/`complete_service()`,

Re: use of #ifdef INET and #ifdef INET6 in the kernel sources

Rick Macklem wrote: [stuff snipped] >The AF_LOCAL code was in head for a short period of time before a vnode lock >panic() >issue was reported and I reverted the patch. > >Here is the commit log message for that reversion: >PR#230752 shows a panic where an nfsd thread tri

Re: use of #ifdef INET and #ifdef INET6 in the kernel sources

Rodney W. Grimes wrote: >Rick Macklem wrote: >> I doubt NFS gets squeezed into such devices and, yes, it is a small amount. >> Using source line counts via "wc" (ir includes comments, etc): >> - This will reduce the # of lines by about 6 for a module of about 7700

Re: use of #ifdef INET and #ifdef INET6 in the kernel sources

Bjoern A. Zeeb wrote: [stuff snipped] I wrote: >> So, is this still recommended for blocks of code that only execute for >> the version >> of IP, but will build for kernels that do not have the particular >> "options INET{6}" >> in the kernel config? > >Yes. Ok, I'll do it. >> If it is still

use of #ifdef INET and #ifdef INET6 in the kernel sources

I thought (can't remember when/how I was told) that it was no longer recommended to add #ifdef INET or #ifdef INET6 to the kernel sources. I'll admit I think #ifdef'ng code when it isn't necessary to get it to build makes the code less readable and, as such, I prefer not to do this. So, is this

correct IP# for NFS kernel upcall to userland daemon

Hi, I have been in a recent discussion about what the correct IP address to use for an upcall from the kernel to the NFS daemon nfsuserd (which maps between uids<->usernames and gids<->group names). The code uses UDP for the upcall (I once committed a patch changing that to an AF_LOCAL socket,

Re: Why rpcb_getaddr(3) uses UDP even for TCP NFS mounts?

Alexey Dokuchaev wrote: >Hi there, > >I've recently encountered a problem that my NFS box was not directly >accessible to one of its clients. I've forwarded TCP ports for the >rpcbind(8), mountd(8), and nfsd(8) with ssh(1), but mount_nfs(8) did >not work, that is, with -o tcp,proto=tcp. >

Re: FCP-0101: Deprecating most 10/100 Ethernet drivers

Warner Losh wrote: [lots of stuff snipped] >That's why that one way to get the driver off the list is to convert to >iflib. That greatly reduces the burden by centralizing all the stupid, >common things of a driver so that we only have to change one place, not >dozens. I can probably do this for

Re: NFS poor performance in ipfw_nat

KIRIYAMA Kazuhiko wrote: [good stuff snipped] > > Thanks for your advice. Add '-lro' and '-tso' to ifconfig, > transfer rate up to almost native NIC speed: > > # dd if=/dev/zero of=/.dake/tmp/foo.img bs=1k count=1m > 1048576+0 records in > 1048576+0 records out > 1073741824 bytes transferred in

Re: Fw: 100.chksetuid handging on nfs mounts

Gerrit Kühn wrote: [stuff snipped] >My impression was that the find commandline is crafted in a way that >should prevent it from touching any filesystems mounted into the root >tree. Maybe I am mistaken here, then hanging on the unavailable nfs mount >is certainly expected (although not nice ;-)

Re: Fw: 100.chksetuid handging on nfs mounts

Gerrit Kühn wrote: >On Thu, 30 Aug 2018 08:07:52 -0600 Alan Somers wrote >about Re: Fw: 100.chksetuid handging on nfs mounts: > >> Well that's not very illuminating. I was wondering if it had weird mount >> options or something. Are you sure that's why find is hanging? What >> happens if you

Re: 9k jumbo clusters

Adrian Chadd wrote: >John-Mark Gurney wrote: [stuff snipped] >> >> Drivers need to be fixed to use 4k pages instead of cluster. I really hope >> no one is using a card that can't do 4k pages, or if they are, then they >> should get a real card that can do scatter/gather on 4k pages for jumbo >>

review of a timeout patch for the kernel RPC

HI, I've created D16293 on reviews.freebsd.org for a patch that sets a timeout for a failed server connected over TCP. The code changes are simple, so the review is more about the technique I used. kib@ has already made a comment. If anyone else would like to comment or review this, it would be

Re: IPv6 scope handling, was Re: svn commit: r335806 - projects/pnfs-planb-server/usr.sbin/nfsd

Andrey V. Elsukov wrote: [stuff snipped] >> >> I think what you are saying above is that a Link-local address won't work >> and that the address must be a global one? >> Should the code check for "fe8" at the start and skip over those ones? > >It is possible that all hosts are in the same scope

Re: IPv6 scope handling, was Re: svn commit: r335806 - projects/pnfs-planb-server/usr.sbin/nfsd

Andrey V. Elsukov wrote: >On 30.06.2018 21:33, Rick Macklem wrote: >>> I'm unaware of applicability of IPv6 addresses with restricted scope in >>> this area, but when you use inet_ntop() to get IPv6 address text >>> representation, you can lost IPv6 scope zone id

IPv6 scope handling, was Re: svn commit: r335806 - projects/pnfs-planb-server/usr.sbin/nfsd

Andrey V. Elsukov wrote: >On 30.06.2018 01:07, Rick Macklem wrote: >> Author: rmacklem >> Date: Fri Jun 29 22:07:25 2018 >> New Revision: 335806 >> URL: https://svnweb.freebsd.org/changeset/base/335806 >> >> Log: >> Add support for IPv6 addres

alignment of ai_addr in struct addrinfo

I have been doing "make universe" for the first time in a long time and I ran into an interesting one. I had code that looked like: struct sockaddr_in *sin; struct addrinfo *res; - did a getaddrinfo() and then after this I had: ... sin = (struct sockaddr_in *)res->ai_addr; For

Re: Starting and stopping nfsd apparently results in permanently disabling it

After a little look at nfsd.c, I think you need to SIGKILL the kernel daemon to get rid of it. (That is what nfsd.c does.) If you do a "ps ax" and find a "nfsd (server)" still there, "kill -9 " it and then you can probably start the nfsd again. rick

Re: mlx5(4) jumbo receive

Ryan Stone wrote: >On Tue, Apr 24, 2018 at 4:55 AM, Konstantin Belousov >>>wrote: >> +#ifndef MLX5E_MAX_RX_BYTES >> +#defineMLX5E_MAX_RX_BYTES MCLBYTES >> +#endif > >Why do you use a 2KB buffer rather than a PAGE_SIZE'd buffer? >MJUMPAGESIZE should offer significantly

Re: Diagnosing terrible ixl performance

I don't know if this post is helpful, but just in case: http://docs.FreeBSD.org/cgi/mid.cgi?04125f40-6388-f074-d935-ce6c16d220fa Hope you don't mind a top post, rick From: owner-freebsd-...@freebsd.org on behalf of hiren

Re: High rate of NFS cache misses after upgrading from 10.3-prerelease to 11.1-release

Niels Kobschätzki wrote: [stuff snipped] >I solved now finally my problem after two weeks and it wasn't the NFS. I >just got derailed from the real solution again and again from some >people, thus I didn't look in the right place. The cache misses are gone >now, the application performs now faster

Re: High rate of NFS cache misses after upgrading from 10.3-prerelease to 11.1-release

Niels Kobschaetzki wrote: [stuff smipped] >I just checked the code to see if I can figure out where exactly I have >to put the printf(). And then I saw that there are ifdefs for >NFS_ACDEBUG which seems to be a kernel option. When I add NFS_ACDEBUG in >the config-file for the kernel, the build

Re: High rate of NFS cache misses after upgrading from 10.3-prerelease to 11.1-release

Niels Kobschaetzki wrote: [stuff snipped] >It is a website with quite some traffic handles by three webservers behind a >pair >of loadbalancers. >We see a loss of 20% in speed(TTFB reduced by 100ms; sounds not a lot but >>Google et al doesn’t like it at all) after upgrading to 11.1 with a

Re: High rate of NFS cache misses after upgrading from 10.3-prerelease to 11.1-release

Niels Kobschätzki wrote: >On 04/14/2018 03:49 AM, Rick Macklem wrote: >> Niels Kobschätzki wrote: >>> sorry for the cross-posting but so far I had no real luck on the forum >>> or on question, thus I want to try my luck here as well. >> I read email lists but do

Re: High rate of NFS cache misses after upgrading from 10.3-prerelease to 11.1-release

Niels Kobschätzki wrote: >sorry for the cross-posting but so far I had no real luck on the forum >or on question, thus I want to try my luck here as well. I read email lists but don't do the other stuff, so I just saw this yesterday. Short answer, I haven't a clue why cache hits rate would have

Re: NFS exports -mapall notworking

Did you check /var/log/messages for any errors related to /etc/exports? (Admittedly this export option probably doesn't get used by many, but I haven't heard from anyone that it is broken.) If there aren't any errors in /var/log/messages, I'd suggest that you post your /etc/exports file and also

re: sosend returning ERESTART

Konstantin Belousov wrote: >On Wed, Jan 18, 2017 at 10:52:02PM +0000, Rick Macklem wrote: >> Colin Percival wrote: >> >On 01/18/17 02:36, Konstantin Belousov wrote: >> >> On Wed, Jan 18, 2017 at 04:37:40AM +, Colin Percival wrote: >> >>> Thanks,

Re: sosend returning ERESTART

Konstantin Belousov wrote: >On Wed, Jan 18, 2017 at 10:52:02PM +0000, Rick Macklem wrote: >> Colin Percival wrote: >> >On 01/18/17 02:36, Konstantin Belousov wrote: >> >> On Wed, Jan 18, 2017 at 04:37:40AM +, Colin Percival wrote: >> >>> Thanks,

Re: sosend returning ERESTART

Konstantin Belousov wrote: >On Wed, Jan 18, 2017 at 10:52:02PM +0000, Rick Macklem wrote: >> Colin Percival wrote: >> >On 01/18/17 02:36, Konstantin Belousov wrote: >> >> On Wed, Jan 18, 2017 at 04:37:40AM +, Colin Percival wrote: >> >>> Thanks,

Re: sosend returning ERESTART

Colin Percival wrote: >On 01/18/17 02:36, Konstantin Belousov wrote: >> On Wed, Jan 18, 2017 at 04:37:40AM +, Colin Percival wrote: >>> Thanks, looks like that was exactly it -- if the TCP send buffer was full >>> we would call sbwait, and if a signal arrived it would return ERESTART. >>> It

Re: sosend returning ERESTART

Colin Percival wrote: >On 01/18/17 02:36, Konstantin Belousov wrote: >> On Wed, Jan 18, 2017 at 04:37:40AM +, Colin Percival wrote: >>> Thanks, looks like that was exactly it -- if the TCP send buffer was full >>> we would call sbwait, and if a signal arrived it would return ERESTART. >>> It

Re: NFSv4 stuck

Slawa Olhovchenkov wrote: [stuff snipped] >> > >> >What data? In may case no data. You have a file system with no files in it. (It is file data I am referring to.) Admittedly a read-only file system won't get corrupted, but you will still have trouble reading files, since NFSv4 require that they

Re: NFSv4 stuck

chenkov wrote: >> >>> On Wed, Jan 11, 2017 at 10:39:42PM +, Rick Macklem wrote: >> >>> >> >>>> "umount -f" is your only chance. However, if there is already a >> >>>> non-forced >> >>>> dismount stuc

Re: NFSv4 stuck

"umount -f" is your only chance. However, if there is already a non-forced dismount stuck, it won't work because the non-forced dismount will have the mounted-on vnode locked. Btw, the processes waiting on "rpccon" are trying to make a new TCP connection to the server. Are you sure the client can

Re: File duplication on NFSv4 exported ZFS filesystems to centos client

Jordan Ladora wrote: >Ahh!! Thank you! > >Previously, I tried exporting just the top-level zfs, but then couldn't >access the zfs filesystems inside from the client, but listing *all* of >them in /etc/exports and only mounting the top-level zfs works perfectly. > >Just wondering, by the way, if

Re: File duplication on NFSv4 exported ZFS filesystems to centos client

Jordan Ladora wrote: >Curious phenomenon of file pseudo-dup with exported ZFS filesystems on >FreeBSD 10.3-REL NFSv4 export to a centos7 client. > > >*FreeBSD server-* > >zpool create zpool_nfsv4 ... > >zfs create zpool_nfsv4/zfs2 > >zfs create zpool_nfsv4/zfs3 > > >/etc/exports- > >V4: / >

Re: NFSv4 exports confusion

Ben Whaley wrote: > Thank you, Rick, for taking the time to reply. > > In an NFSv4 server, is it possible to have multiple exports on the same > filesystem but not under the same tree without exposing the top level > directory? No. The same is actually true for NFSv3, except that the Mount

Re: NFSv4 exports confusion

Ben Whaley wrote: > Hi all, > > I’m probably just misunderstanding something pretty basic here so apologies > if that’s the case. > > The NFSv4 pseudo-filesystem root is not behaving the way I’d expect. > Consider the following extremely simple /etc/exports (just for example > purposes): FreeBSD

Re: NFS on 10G interfaces still painfully slow

Alan Somers wrote: >On Tue, Aug 2, 2016 at 2:49 AM, Gerrit Kühn wrote: >> Hi all, >> >> I already reported this issue here a year ago and unfortunately was not >> able to fix it back then. Now I had another run at it, using two recent >> 10.3-machines with a direct 10G

  1   2   3   >