On Thu, Nov 7, 2024 at 9:41 PM George Neville-Neil
wrote:
>
>
>
> On 7 Nov 2024, at 13:59, Rick Macklem wrote:
>
> > On Thu, Nov 7, 2024 at 9:34 AM George Neville-Neil
> > wrote:
> >>
> >>
> >>
> >> On 7 Nov 2024, at 4:15, Mark Saa
On Thu, Nov 7, 2024 at 2:09 PM Mark Johnston wrote:
>
> On Thu, Nov 07, 2024 at 07:28:59AM +0200, Andriy Gapon wrote:
> > On 07/11/2024 02:43, George Neville-Neil wrote:
> > > Howdy,
> > >
> > > We've been digging into an interesting possible issue in the FreeBSD NFS
> > > client. Here is the scen
On Thu, Nov 7, 2024 at 9:34 AM George Neville-Neil
wrote:
>
>
>
> On 7 Nov 2024, at 4:15, Mark Saad wrote:
>
> >>
> >> On Nov 7, 2024, at 12:29 AM, Andriy Gapon wrote:
> >>
> >> On 07/11/2024 02:43, George Neville-Neil wrote:
> >>> Howdy,
> >>> We've been digging into an interesting possible is
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.
>> >
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.
>
>
> > On
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
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
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
>
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.
> >
>
>
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 contains
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.
>
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 haven'
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
> > -138
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 reportin
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 wonderin
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 ther
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
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 picking
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
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 from outside of the University of Guelph. D
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 from outs
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:
nc
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
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: Yo
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
>
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 additio
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
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
C.
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"
ld like to understand why the 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.
>
> Thank
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
>>
&
S val 2074098279 ecr 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
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; fre
nfirm if the above is 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.
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
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.patc
AL
Sent: Saturday, March 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 i
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 linux-...@ver.
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 t
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 $wor
re information w.r.t 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.
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
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 guy
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
s
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 >
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 NFSv
ance/window sizing in TCP.
And the list goes on 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'
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 months
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 months
ords 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 relo
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
>>
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
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
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
___
freebsd-net@fr
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 panic&#
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
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, rick
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 directi
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 file.
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 cha
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 >clien
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 a
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
>>>>
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 or
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()`,
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 tries to
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
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 recom
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
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, bu
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.
>
>Running
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 b
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 10.
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 ;-) be
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 un
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
>> fr
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
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 zon
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 zo
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
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 m
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
___
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 better performance fo
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 panchasara
Sent: Friday, April 2
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
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 fail
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 combine
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
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 cha
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
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,
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,
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,
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 lo
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 lo
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 b
nkov 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
"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
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 yo
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: /
>
>/zpool
1 - 100 of 276 matches
Mail list logo
