Re: releng/13 release/13.0.0 : odd/incorrect diff result over nfs (in a zfs file systems context)

Mark Millard wrote: [stuff snipped] >Well, why is it that ls -R, find, and diff -r all get file >name problems via genet0 but diff -r gets no problems >comparing the content of files that it does match up (the >vast majority)? Any clue how could the problems possibly >be unique to the handling of

Re: releng/13 release/13.0.0 : odd/incorrect diff result over nfs (in a zfs file systems context)

Mark Millard wrote: >On 2021-May-20, at 22:19, Rick Macklem wrote: [stuff snipped] >> ps: I do not think that r367492 could cause this, but it would be >> nice if you try a kernel with the r367492 patch reverted. >> It is currently in all of releng13, stable

Re: releng/13 release/13.0.0 : odd/incorrect diff result over nfs (in a zfs file systems context)

__ From: Mark Millard Sent: Friday, May 21, 2021 12:40 AM To: Rick Macklem Cc: FreeBSD-STABLE Mailing List Subject: Re: releng/13 release/13.0.0 : odd/incorrect diff result over nfs (in a zfs file systems context) CAUTION: This email originated from outside of the University of Guelph.

Re: releng/13 release/13.0.0 : odd/incorrect diff result over nfs (in a zfs file systems context)

reebsd-sta...@freebsd.org on behalf of Rick Macklem Sent: Thursday, May 20, 2021 8:55 PM To: FreeBSD-STABLE Mailing List; Mark Millard Subject: Re: releng/13 release/13.0.0 : odd/incorrect diff result over nfs (in a zfs file systems context) Mark Millard wrote: >[I warn that I'm a fairly minimal user o

Re: releng/13 release/13.0.0 : odd/incorrect diff result over nfs (in a zfs file systems context)

Mark Millard wrote: >[I warn that I'm a fairly minimal user of NFS >mounts, not knowing all that much. I'm mostly >reporting this in case it ends up as evidence >via eventually matching up with others observing >possibly related oddities.] > >I got the following odd sequence (that I've >mixed

Re: wanna solve the Linux NFSv4 client puzzle?

Rick Macklem wrote: >Hi, > >I posted recently that enabling delegations should be avoided at this time, >especially if your FreeBSD NFS server has Linux client mounts... > >I thought some of you might be curious why, and I thought it would be >more fun if you look for yourselv

wanna solve the Linux NFSv4 client puzzle?

Hi, I posted recently that enabling delegations should be avoided at this time, especially if your FreeBSD NFS server has Linux client mounts... I thought some of you might be curious why, and I thought it would be more fun if you look for yourselves. To play the game, you need to download a

NFSv4 issues related to delegations and the back channel

Hi, A problem with the NFSv4.1/4.2 server was identified, where it erroneously bound the back channel on a new TCP connection was identified, that could break the Linux client. Fixing this has cascaded into a fair number of patches to make the back channel work correctly. Since use of delegations

Re: Deprecating base system ftpd?

Dave Cottlehuber wrote: >> On 03/04/2021 22:39, Ed Maste wrote: >> > I propose deprecating the ftpd currently included in the base system >> > before FreeBSD 14, and opened review D26447 >> > (https://reviews.freebsd.org/D26447) to add a notice to the man page. >> > I had originally planned to try

Re: Deprecating base system ftpd?

Eugene Grosbein wrote: >04.04.2021 3:39, Ed Maste wrote: > >> I propose deprecating the ftpd currently included in the base system >> before FreeBSD 14, and opened review D26447 >> (https://reviews.freebsd.org/D26447) to add a notice to the man page. >> I had originally planned to try to do this

Re: FreeBSD NFSv4.1/4.2 server is broken when Linux mounts use "nconnects"

Alan Somers wrote: >On Mon, Mar 29, 2021 at 3:52 PM Rick Macklem >mailto:rmack...@uoguelph.ca>> wrote: >>Hi, >> >>The FreeBSD NFS server is broken when handling multiple >>connections for NFSv4.1/4.2. >>It incorrectly binds the back channel to a new conn

FreeBSD NFSv4.1/4.2 server is broken when Linux mounts use "nconnects"

Hi, The FreeBSD NFS server is broken when handling multiple connections for NFSv4.1/4.2. It incorrectly binds the back channel to a new connection when is sees an RPC with Sequence in it (almost all RPCs) and might send a callback on the wrong connection. I have a fix, but it won't be in a

Re: Documentation regarding NFSv4

ed, you'll see lots of files owned by "nobody" on the client mounts. rick ________ From: Rick Macklem Sent: Friday, September 18, 2020 7:21 PM To: Shawn Webb; freebsd-curr...@freebsd.org; freebsd-stable@freebsd.org Subject: Re: Documentation regarding NFSv

Re: Documentation regarding NFSv4

Shawn Webb wrote: >Hey all, > >It appears the Handbook and the nfsv4 manpages don't really agree, >leading to some confusion as to how to properly set up an NFSv4 server >on FreeBSD. > >Any guidance would be appreciated. 1 - I never look at the Handbook, but do try and maintain the man pages.

Re: zfs meta data slowness

mike tancsa wrote: >Hi, >Thanks for the response. Reply in line > >On 7/20/2020 9:04 AM, Ronald Klop wrote: >> Hi, >> >> My first suggestion would be to remove a lot of snapshots. But that my >> not match your business case. > >As its a backup server, its sort of the point to have all those

Re: nfs lockd errors after NetApp software upgrade.

sday, 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 NF

Re: nfs lockd errors after NetApp software upgrade.

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

Re: nfs lockd errors after NetApp software upgrade.

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; freebs

Re: nfs lockd errors after NetApp software upgrade.

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

Re: nfs lockd errors after NetApp software upgrade.

Daniel Braniss wrote: >> On 21 Dec 2019, at 19:32, Rick Macklem wrote: >> >> Daniel Braniss wrote: >>>> On 20 Dec 2019, at 19:19, Rick Macklem >>>> >>>mailto:rmack...@uoguelph.ca>> wrote: >>>> >>>> Adam McDougall w

Re: nfs lockd errors after NetApp software upgrade.

Daniel Braniss wrote: >>On 20 Dec 2019, at 19:19, Rick Macklem >>>>mailto:rmack...@uoguelph.ca>> wrote: >> >>Adam McDougall wrote: >>>Try changing bool_t do_tcp = FALSE; to TRUE in >>>/usr/src/sys/nlm/nlm_prot_impl.c, recompile the kernel and

Re: nfs lockd errors after NetApp software upgrade.

On 12/19/19 9:21 AM, Daniel Braniss wrote: > > >> On 19 Dec 2019, at 16:09, Rick Macklem wrote: >> >> Daniel Braniss wrote: >> [stuff snipped] >>> all mounts are nfsv3/tcp >> This doesn't affect what the NLM code (rpc.lockd) uses. I honestly don't >

Re: nfs lockd errors after NetApp software upgrade.

. rick cheers, danny > rick > > Cheers > > Richard > (NetApp admin) > > On Wed, 18 Dec 2019 at 15:46, Daniel Braniss > mailto:da...@cs.huji.ac.il>> wrote: > > >> On 18 Dec 2019, at 16:55, Rick Macklem >> mailto:rmack...@uoguelph

Re: nfs lockd errors after NetApp software upgrade.

46, Daniel Braniss mailto:da...@cs.huji.ac.il>> wrote: > On 18 Dec 2019, at 16:55, Rick Macklem > mailto:rmack...@uoguelph.ca>> wrote: > > Daniel Braniss wrote: > >> Hi, >> The server with the problems is running FreeBSD 11.1 stable, it was working >> fine

Re: nfs lockd errors after NetApp software upgrade.

Daniel Braniss wrote: >Hi, >The server with the problems is running FreeBSD 11.1 stable, it was working >fine for >several months, >but after a software upgrade of our NetAPP server it’s reporting many lockd >errors >and becomes catatonic, >... >Dec 18 13:11:02 moo-09 kernel: nfs server

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

Patch to improve mountd performance for reload of exports

Hi, I have created PR#237860 to keep track of a patch I have to try and improve the performance of mountd when reloading exports for an NFS server with a lot of file systems. Peter reported that the nfsd threads would be stalled for 16sec when exports were reloaded (via SIGHUP) for his file

Re: FreeBSD 12.0 RELEASE i386 can not build a kernel?

Rodney W. Grimes wrote: >config CUSTOM >Kernel build directory is ../compile/CUSTOM >Don't forget to do ``make cleandepend && make depend'' >fb-bld-120-i386.dnsmgr.net:root {200}# cd ../compile/CUSTOM >fb-bld-120-i386.dnsmgr.net:root {201}# (make cleandepend && make depend && >>make -j4 && make

Re: FreeBSD-12.0-RC3-i386-disc1.iso does not boot

miltonott wrote: >>On Sat Dec 1 21:51:05 UTC 2018 CenturyLink Customer wrote: >>> Hello all:Sorry, this old Pentium 4 refurbished test machine has been >>> obstinate >>> during ALPHA, BETA, and now RC.I had a workaround using the BTX bootloader >>> from >>> ALPHA8 and pasted it into BETA3;

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: FreeBSD 11.2-RELEASE - mountd problem - mountd[1056]: unknown user: root

John Newman wrote: >I'm having a problem with one of my FreeBSD NFS servers. It's an >11.2-RELEASE box (upgraded fairly recently from 10.1), and actually >we had the same issue even when it was on 10.x. > >Basically, what is happening is several of my NFS exports that are >configured with

Do you use NFS for ESXi 6.5 on old hardware?

Hi, Recent work has determines that ESXi 6.7 works much better with the FreeBSD NFS server for NFSv4.1 than ESXi 6.5 does. (Once a patch not yet in head/current is committed.) I don't think support for ESXi 6.5 for NFSv4.1 is practical. ESXi 6.5 can use NFSv3 or iSCSI to use a FreeBSD server.

Re: NFS 4.1 RECLAIM_COMPLETE FS failed error

Daniel Engel wrote: [stuff snipped] >I traced the commits that Rick has made since that thread and merged them >'head' >into 'stable': > >'svnlite checkout http://svn.freebsd.org/base/release/11.1.0/' >'svnlite merge -c 332790 http://svn.freebsd.org/base/head' >'svnlite merge -c

Re: NFS 4.1 RECLAIM_COMPLETE FS failed error

Daniel Engel wrote: >I am setting up an environment with FreeBSD 11.1 sharing a ZFS datastore to >vmware >ESXI 6.7. There were a number of errors with NFS 4.1 sharing that I >didn't >understand until I found the following thread. > >

Re: Console is broken after updating to 11.2-RELEASE

Chris H wrote: [stuff snipped] >> >> Thank you for information. I added above lines to /boot/loader.conf >> and rebooted system. Then all boot messages are displayed and console >> works fine! > >WooHoo! :-) > >I could make further observations based on *why* that worked. But several >are likely,

Re: NFS 4.1 RECLAIM_COMPLETE FS failed error in combination with ESXi client

NAGY Andreas wrote: >Thanks! Please keep me updated if you find put more or when a updated version >is available. Will try to remember to do so. >As I now know it is working, I will start tomorrow to build up a testsystem >with 3 NFS servers >(two of them in a ha with CARP and HAST) and several

Re: NFS 4.1 RECLAIM_COMPLETE FS failed error in combination with ESXi client

NAGY Andreas wrote: >Thanks, the not issuing delegation warnings disappeared with this patch. > >But now there are some new warnings I haven't seen so far: >2018-03-10T13:01:39.441Z cpu8:68046)WARNING: NFS41: NFS41FSOpGetObject:2148: >Failed to >get object 0x43910e71b386 [36 c6b10167 9b157f95

Re: NFS 4.1 RECLAIM_COMPLETE FS failed error in combination with ESXi client

NAGY Andreas wrote: >>I'll take another look and see if I can guess why it doesn't like "2" as a >>reason for >not issuing a delegation. (As noted before, I don't think this is >>serious, but???) > >This warnings are still there, but don't seem to have any impact. It looks >like they >only

Re: NFS 4.1 RECLAIM_COMPLETE FS failed error in combination with ESXi client

NAGY Andreas wrote: >Actually I have only made some quick benchmarks with ATTO in a Windows VM >>which has a vmdk on the NFS41 datastore which is mounted over two 1GB links >in >different subnets. >Read is nearly the double of just a single connection and write is just a bit >faster. >Don't

Re: NFS 4.1 RECLAIM_COMPLETE FS failed error in combination with ESXi client

NAGY Andreas wrote: >- after a reboot of the FreeBSD machine the ESXi does not restore the NFS >>datastore again with following warning (just disconnecting the links is fine) >2018-03-08T12:39:44.602Z cpu23:66484)WARNING: NFS41: > >NFS41_Bug:2361: BUG - Invalid

Re: NFS 4.1 RECLAIM_COMPLETE FS failed error in combination with ESXi client

NAGY Andreas wrote: >Thanks you, really great how fast you adapt the source/make patches for this. >Saw so many >posts were people did not get NFS41 working with ESXi and FreeBSD >and now I have it already >running with your changes. > >I have now compiled the kernel with all 4 patches, and it

Re: NFS 4.1 RECLAIM_COMPLETE FS failed error in combination with ESXi client

NAGY Andreas wrote: >attached the trace. If I see it correct it uses FORE_OR_BOTH. (bctsa_dir: >>CDFC4_FORE_OR_BOTH (0x0003)) Yes. The scary part is the ExchangeID before the BindConnectiontoSession. (Normally that is only done at the beginning of a new mount to get a ClientID, followed

Re: NFS 4.1 RECLAIM_COMPLETE FS failed error in combination with ESXi client

NAGY Andreas wrote: >Okay, that was the main reason for using NFS 4.1. >Is it planned to implement it, or is the focus on pNFS? I took a quick look and implementing this for some cases will be pretty easy. Binding a FORE channel is implied, so for that case all the server does is reply OK to the

Re: NFS 4.1 RECLAIM_COMPLETE FS failed error in combination with ESXi client

NAGY Andreas wrote: >Compiling with the last patch also failed: > >error: use of undeclared identifier 'NFSV4OPEN_WDSUPPFTYPE If you apply the attached patch along with wantdeleg.patch, it should build. At most, this will get rid of the warnings about invalid reason for not issuing a delegation,

Re: NFS 4.1 RECLAIM_COMPLETE FS failed error in combination with ESXi client

NAGY Andreas wrote: >Okay, that was the main reason for using NFS 4.1. >Is it planned to implement it, or is the focus on pNFS? Do the VMware people claim that this improves performance? (I know nothing about the world of VMs, but for real hardware I can't see any advantage of having more than

Re: NFS 4.1 RECLAIM_COMPLETE FS failed error in combination with ESXi client

Nope, that isn't supported, rick (Hope no one is too upset by a top post.) From: NAGY Andreas <andreas.n...@frequentis.com> Sent: Monday, March 5, 2018 8:22:10 AM To: Rick Macklem; 'freebsd-stable@freebsd.org' Subject: RE: NFS 4.1 RECLAIM_COMPL

Re: DEQNA support in stable ???! Errrr.....

Warner Losh wrote: >On Sun, Mar 4, 2018 at 3:45 PM, Pete French >wrote: >> >> Unless my memory fails me DEQNA is the Dec Q-bus network adapter >> for MicroVaxen isn't it ? The mini version of the DEUNA interface for >> the full size Vax/11 machines. Now, I woudn't be

Re: NFS 4.1 RECLAIM_COMPLETE FS failed error in combination with ESXi client

NAGY Andreas wrote: [stuff snipped] >In the source I saw nfs_async = 0; is it right that NFS will work in async >mode if I >compile the kernel with nfs_async = 1? > >I know the risk of running it async, but is it not the same risk having the >datastore >connected via iSCSI which standard is also

Re: NFS 4.1 RECLAIM_COMPLETE FS failed error in combination with ESXi client

NAGY Andreas wrote: >Hi and thanks! > >First time using/needing a patch could you give me a short advise how to use >it >and for which version? The only difference with kernel versions will be the line#s. >So far I have made a fresh FreeBSD 11.1 RELEASE install as a VM on a ESXi host >>updated

Re: NFS 4.1 RECLAIM_COMPLETE FS failed error in combination with ESXi client

NAGY Andreas wrote: >I am trying to get a FreeBSD NFS 4.1 export working with VMware Esxi 6.5u1, >but >it is always mounted as read only. > >After some research, I found out that this is a known problem, and there are >>threads about this from 2015 also in the mailinglist archive. > >As it seems

Re: kernel process [nfscl] high cpu

break within jails, so fixing the nfsuserd situation may not resolve your problems. rick From: Fabian Freyer <fabian.fre...@physik.tu-berlin.de> Sent: Sunday, October 15, 2017 4:45:00 PM To: freebsd-stable@freebsd.org Cc: Rick Macklem; li...@searchy.

Re: recommendations for file server based zfs appliance

Patrick M. Hausen wrote: >Hi, all, > >> Am 18.08.2017 um 11:19 schrieb Pete French : >> The HP micro servers work very well, and you can pick them up remakably >> cheaply [...] >> Not sure about ECC memory support there though. > >They do support ECC, no problem. >

Re: Extended "system" attributes within jailed environment dont work

Konstantin Belousov wrote: >On Fri, Jul 14, 2017 at 07:28:58PM +1000, Dewayne Geraghty wrote: [stuff snipped] >> >> I suppose that the crux to the question is - why should the "system" >> namespace not be available within a jail? >Perhaps because system namespace (can) carry attributes which

Re: Recent FreeBSD, NFSv4 and /var/db/mounttab

Claude Buisson wrote: >On 05/07/2017 21:09, Rick Macklem wrote: >> Claude Buisson wrote: >>> Hi, >>> >>> Last month, I started switching all my systems (stable/9, stable/10, >>> stable/11 and current) to NFSv4, and I found that: >>> >

Re: Recent FreeBSD, NFSv4 and /var/db/mounttab

Claude Buisson wrote: [stuff snipped] > This is really an long delayed answer !! Just made it to the top of my "to do" list... > 1) I am afraid of a confusion on your side between mounttab which is > managed on the CLIENT, and mountdtab which is managed of the SERVER. Ok, now that I've looked, I

Re: Recent FreeBSD, NFSv4 and /var/db/mounttab

Claude Buisson wrote: >Hi, > >Last month, I started switching all my systems (stable/9, stable/10, >stable/11 and current) to NFSv4, and I found that: > > on current (svn 312652) an entry is added to /var/db/mounttab by >mount_nfs(8), but not suppressed by umount(8). It can be suppressed by

Re: unionfs bugs, a partial patch and some comments [Was: Re: 1-BETA3 Panic: __lockmgr_args: downgrade a recursed lockmgr nfs @ /usr/local/share/deploy-tools/RELENG_11/src/sys/fs/unionfs/union_vnops.c

Konstantin Belousov wrote: > I did not touched unionfs, and have no plans to. It is equally broken in > all relevant versions of FreeBSD. Heh, heh. I chuckled when I read this. I think he's trying to say "it probably won't ever be fixed". My understanding is that it would require a major redesign

Re: unionfs bugs, a partial patch and some comments [Was: Re: 1-BETA3 Panic: __lockmgr_args: downgrade a recursed lockmgr nfs @ /usr/local/share/deploy-tools/RELENG_11/src/sys/fs/unionfs/union_vnops.c

Hmm, this is going to sound dumb, but I don't recall generating any unionfs patch;-) I'll go look for it. Maybe it was Kostik's? rick From: Harry Schmalzbauer <free...@omnilan.de> Sent: Tuesday, March 7, 2017 2:45:40 PM To: Rick Macklem Cc: Kons

Re: 'show alllocks' of completely locked machine [Was: Re: Complete IO lockup, state "ufs" from userland, debuging help wanted]

hiren panchasara wrote: [sorry, I can't be bothered manually indenting it all, so just see my comment at the end] On 03/06/17 at 08:56P, Harry Schmalzbauer wrote: > Bez?glich Harry Schmalzbauer's Nachricht vom 05.03.2017 22:59 (localtime): > > Hello, > > > > I can easily lock up FreeBSD

Re: Recent FreeBSD, NFSv4 and /var/db/mounttab

Claude Buisson wrote: >Hi, > >Last month, I started switching all my systems (stable/9, stable/10, >stable/11 and current) to NFSv4, and I found that: > > on current (svn 312652) an entry is added to /var/db/mounttab by >mount_nfs(8), but not suppressed by umount(8). It can be suppressed by

Re: NFS and amd on older FreeBSD

Do you have exactly the same export options specified in /etc/exports for the 9.3 server as the 6.3 one? Beyond that, I can only suggest capturing packets when the automount fails and looking at them in wireshark to see what is actually happening. rick

Re: stable/11 build fails @r306629; I suspect r306609

From: owner-freebsd-sta...@freebsd.org <owner-freebsd-sta...@freebsd.org> on behalf of Konstantin Belousov <kostik...@gmail.com> Sent: Monday, October 3, 2016 7:54:09 AM To: David Wolfskill; sta...@freebsd.org; Rick Macklem Subject: Re: stable/11 build fails @r30662

Re: unionfs bugs, a partial patch and some comments [Was: Re: 1-BETA3 Panic: __lockmgr_args: downgrade a recursed lockmgr nfs @ /usr/local/share/deploy-tools/RELENG_11/src/sys/fs/unionfs/union_vnops.c

Harry Schmalzbauer wrote: >Bezüglich Rick Macklem's Nachricht vom 18.08.2016 02:03 (localtime): >> Kostik wrote: >> [stuff snipped] >>> insmnque() performs the cleanup on its own, and that default cleanup isnot >>> suitable >for the situation. I think that insmntque1()

Re: unionfs bugs, a partial patch and some comments [Was: Re: 1-BETA3 Panic: __lockmgr_args: downgrade a recursed lockmgr nfs @ /usr/local/share/deploy-tools/RELENG_11/src/sys/fs/unionfs/union_vnops.c

Kostik wrote: [stuff snipped] >insmnque() performs the cleanup on its own, and that default cleanup isnot >suitable >for the situation. I think that insmntque1() would betterfit your >requirements, your >need to move the common code into a helper.It seems that >>unionfs_ins_cached_vnode()

Re: unionfs bugs, a partial patch and some comments [Was: Re: 1-BETA3 Panic: __lockmgr_args: downgrade a recursed lockmgr nfs @ /usr/local/share/deploy-tools/RELENG_11/src/sys/fs/unionfs/union_vnops.c

Harry Schmalzbauer wrote: Bezüglich Mark Johnston's Nachricht vom 09.08.2016 08:02 (localtime): … >> >> Just for anybody else needing unionfs: >> https://people.freebsd.org/~attilio/unionfs_missing_insmntque_lock.patch >> >> This patch still applies and I'm successfully using this (unmodified) up

Re: 1-BETA3 Panic: __lockmgr_args: downgrade a recursed lockmgr nfs @ /usr/local/share/deploy-tools/RELENG_11/src/sys/fs/unionfs/union_vnops.c:1905

Harry Schmalzbauer wrote: > Hello, > > I had another crash which I'm quite sure was triggered by mount_unionfs: Just in case you are not already aware, unionfs is always broken. Read the BUGS section at the end of "man mount_unionfs". If it were easy to fix, someone would have done so long ago.

Re: kernel process [nfscl] high cpu

Frank de Bot wrote: > Rick Macklem wrote: > > Frank de Bot wrote: > >> Rick Macklem wrote: > >>> Frank de Bot wrote: > >>>> Hi, > >>>> > >>>> On a 10.1-RELEASE-p9 server I have several NFS mounts used for a

Re: cp from NFS to ZFS hung in "fifoor"

Mikhail T. wrote: > On 28.11.2015 17:41, Jilles Tjoelker wrote: > > Although cp -R will normally copy a fifo by calling mkfifo at the > > destination, it may open one if a regular file is replaced with a fifo > > between the time it reads the directory and it copies that file. > > The sole fifo

Re: cp from NFS to ZFS hung in "fifoor"

Mikhail T. wrote: > On 28.11.2015 17:41, Jilles Tjoelker wrote: > > Although cp -R will normally copy a fifo by calling mkfifo at the > > destination, it may open one if a regular file is replaced with a fifo > > between the time it reads the directory and it copies that file. > > The sole fifo

Re: cp from NFS to ZFS hung in "fifoor"

Mikhail T. wrote: > I was copying /home from an old server (narawntapu) to a new one > (aldan). The narawntapu:/home is mounted on aldan as /mnt with flags > ro,intr. On narawntapu /home was simply located on an SSD, but on aldan > I created a ZFS filesystem for it. > > The copying was started

Re: cp from NFS to ZFS hung in "fifoor"

Jilles Tjoelker wrote: > On Sat, Nov 28, 2015 at 10:42:28AM -0500, Mikhail T. wrote: > > I was copying /home from an old server (narawntapu) to a new one > > (aldan). The narawntapu:/home is mounted on aldan as /mnt with flags > > ro,intr. On narawntapu /home was simply located on an SSD, but on

Re: smbfs crashes since approx. 10.1-RELEASE

Christian Kratzer wrote: > Hi Rick, > > On Sun, 18 Oct 2015, Rick Macklem wrote: > > > Christian Kratzer wrote: > >> Hi Rick, > >> > >> looks like your latest patch nailed the issue. The box has been up for 3 > >> days: > >> >

Re: smbfs crashes since approx. 10.1-RELEASE

t smbiod *iod) > { > smb_iod_request(iod, SMBIOD_EV_SHUTDOWN | SMBIOD_EV_SYNC, NULL); > - smb_sl_destroy(>iod_rqlock); > - smb_sl_destroy(>iod_evlock); > - free(iod, M_SMBIOD); > return 0; > } > > ck@noc3:/usr/src % > >

Re: smbfs crashes since approx. 10.1-RELEASE

r from the folk that reported the PRs. John, maybe you could review this? Thanks for your help testing this, rick > Greetings > Christian > > > > On Mon, 12 Oct 2015, Rick Macklem wrote: > > > Christian Kratzer wrote: > >> Hi Rick, > >> >

Re: smbfs crashes since approx. 10.1-RELEASE

xception.S:396 > #13 0x00080089190a in ?? () > Previous frame inner to this frame (corrupt stack?) > Current language: auto; currently minimal > (kgdb) > > > Greetings > Christian > > > > > > > > > > >

Re: smbfs crashes since approx. 10.1-RELEASE

Christian Kratzer wrote: > Hi Rick, > > On Mon, 12 Oct 2015, Rick Macklem wrote: > > > Christian Kratzer wrote: > >> Hi Rick, > >> > >> there was also a second more recent crash in /var/crash > >> > >> Mon Oct 12 03:01:16 CEST

Re: smbfs crashes since approx. 10.1-RELEASE

Hi again, Attached is a semantically equivalent patch to the one I posted a few minutes ago, but I think this one is more readable. Please let me know if you get it tested, rick - Original Message - > Hi John, > > the box crashed again running a 10-stable kernel with following patch of

Re: smbfs crashes since approx. 10.1-RELEASE

Hi, Maybe you could try the attached patch instead of the one below? (Completely untested. I haven't even tried to compile it.) rick - Original Message - > Hi John, > > the box crashed again running a 10-stable kernel with following patch of > yours: > > On Wed, 7 Oct 2015, John

Re: smbfs crashes since approx. 10.1-RELEASE

Christian Kratzer wrote: > Hi John, > > the box crashed again running a 10-stable kernel with following patch of > yours: > > On Wed, 7 Oct 2015, John Baldwin wrote: > > Index: smb_iod.c > > === > > --- smb_iod.c (revision 288952)

Re: ix(intel) vs mlxen(mellanox) 10Gb performance

Hans Petter Selasky wrote: > Hi, > > I've now MFC'ed r287775 to 10-stable and 9-stable. I hope this will > resolve the issues with m_defrag() being called on too long mbuf chains > due to an off-by-one in the driver TSO parameters and that it will be > easier to maintain these parameters in the

Re: smbfs crashes since approx. 10.1-RELEASE

Christian Kratzer wrote: > Hi, > > I run a regular rsync job that runs from cron and copies stuff that gets > created on a Windows smbfs share. > > Starting about 10.1-RELEASE the VM has become unstable and started panicing. > > I have narrowed the issue down to the aforementioned rsync job. >

Re: kernel process [nfscl] high cpu

Frank de Bot wrote: > Rick Macklem wrote: > > Frank de Bot wrote: > >> Hi, > >> > >> On a 10.1-RELEASE-p9 server I have several NFS mounts used for a > >> jail. > >> Because it's a server only to test, there is a low load. But the &g

Re: kernel process [nfscl] high cpu

Frank de Bot wrote: > Rick Macklem wrote: > > Frank de Bot wrote: > >> Rick Macklem wrote: > >>> Frank de Bot wrote: > >>>> Hi, > >>>> > >>>> On a 10.1-RELEASE-p9 server I have several NFS mounts used for a

Re: kernel process [nfscl] high cpu

Frank de Bot wrote: > Rick Macklem wrote: > > Frank de Bot wrote: > >> Rick Macklem wrote: > >>> Frank de Bot wrote: > >>>> Hi, > >>>> > >>>> On a 10.1-RELEASE-p9 server I have several NFS mounts used for a

Re: NFS Client changing it's source address? (FreeBSD 10.2)

Frank de Bot wrote: Hello, I have a server running FreeBSD 10.2. It has several NFS mounts. Frequently my NFS mount hang (v3). After a little investigation it looks like FreeBSD has chosen a wrong source address for it's connections and all packets are departing from the wrong interface.

Re: NFS Client changing it's source address? (FreeBSD 10.2)

I wrote: - Reconfigure your NFS server so that it never drops idle TCP connections. (FreeBSD never drops an NFS TCP connection until umount, but some others like Solaris NFS servers drop idle connections.) Oops, I forgot that the kernel RPC (I wasn't the author) does drop idle TCP

Re: dev.ix.0.queueX.interrupt_rate

Gerritt Kuhn wrote: On Mon, 24 Aug 2015 22:29:26 +0300 Slawa Olhovchenkov s...@zxy.spb.ru wrote about dev.ix.0.queueX.interrupt_rate: SO Last -stable, no tuning. Is this normal? From 10.2-rel (and still having severe performance issues with NFS as reported before):

Re: ix(intel) vs mlxen(mellanox) 10Gb performance

Daniel Braniss wrote: On 24 Aug 2015, at 10:22, Hans Petter Selasky h...@selasky.org wrote: On 08/24/15 01:02, Rick Macklem wrote: The other thing is the degradation seems to cut the rate by about half each time. 300--150--70 I have no idea if this helps to explain it. Might

Re: ix(intel) vs mlxen(mellanox) 10Gb performance

Daniel Braniss wrote: On 22 Aug 2015, at 14:59, Rick Macklem rmack...@uoguelph.ca wrote: Daniel Braniss wrote: On Aug 22, 2015, at 12:46 AM, Rick Macklem rmack...@uoguelph.ca wrote: Yonghyeon PYUN wrote: On Wed, Aug 19, 2015 at 09:00:35AM -0400, Rick Macklem wrote: Hans

Re: ix(intel) vs mlxen(mellanox) 10Gb performance

Daniel Braniss wrote: On Aug 22, 2015, at 12:46 AM, Rick Macklem rmack...@uoguelph.ca wrote: Yonghyeon PYUN wrote: On Wed, Aug 19, 2015 at 09:00:35AM -0400, Rick Macklem wrote: Hans Petter Selasky wrote: On 08/19/15 09:42, Yonghyeon PYUN wrote: On Wed, Aug 19, 2015 at 09:00:52AM

Re: ix(intel) vs mlxen(mellanox) 10Gb performance

Yonghyeon PYUN wrote: On Wed, Aug 19, 2015 at 09:00:35AM -0400, Rick Macklem wrote: Hans Petter Selasky wrote: On 08/19/15 09:42, Yonghyeon PYUN wrote: On Wed, Aug 19, 2015 at 09:00:52AM +0200, Hans Petter Selasky wrote: On 08/18/15 23:54, Rick Macklem wrote: Ouch! Yes, I now see

Re: ix(intel) vs mlxen(mellanox) 10Gb performance

Yonghyeon PYUN wrote: On Wed, Aug 19, 2015 at 08:13:59AM -0400, Rick Macklem wrote: Yonghyeon PYUN wrote: On Wed, Aug 19, 2015 at 09:51:44AM +0200, Hans Petter Selasky wrote: On 08/19/15 09:42, Yonghyeon PYUN wrote: On Wed, Aug 19, 2015 at 09:00:52AM +0200, Hans Petter Selasky wrote

Re: ix(intel) vs mlxen(mellanox) 10Gb performance

Hans Petter Selasky wrote: On 08/19/15 09:42, Yonghyeon PYUN wrote: On Wed, Aug 19, 2015 at 09:00:52AM +0200, Hans Petter Selasky wrote: On 08/18/15 23:54, Rick Macklem wrote: Ouch! Yes, I now see that the code that counts the # of mbufs is before the code that adds the tcp/ip header

Re: ix(intel) vs mlxen(mellanox) 10Gb performance

Hans Petter Selasky wrote: On 08/19/15 09:42, Yonghyeon PYUN wrote: On Wed, Aug 19, 2015 at 09:00:52AM +0200, Hans Petter Selasky wrote: On 08/18/15 23:54, Rick Macklem wrote: Ouch! Yes, I now see that the code that counts the # of mbufs is before the code that adds the tcp/ip header

Re: ix(intel) vs mlxen(mellanox) 10Gb performance

Hans Petter Selasky wrote: On 08/19/15 09:42, Yonghyeon PYUN wrote: On Wed, Aug 19, 2015 at 09:00:52AM +0200, Hans Petter Selasky wrote: On 08/18/15 23:54, Rick Macklem wrote: Ouch! Yes, I now see that the code that counts the # of mbufs is before the code that adds the tcp/ip header

Re: ix(intel) vs mlxen(mellanox) 10Gb performance

Yonghyeon PYUN wrote: On Wed, Aug 19, 2015 at 09:51:44AM +0200, Hans Petter Selasky wrote: On 08/19/15 09:42, Yonghyeon PYUN wrote: On Wed, Aug 19, 2015 at 09:00:52AM +0200, Hans Petter Selasky wrote: On 08/18/15 23:54, Rick Macklem wrote: Ouch! Yes, I now see that the code that counts

Re: ix(intel) vs mlxen(mellanox) 10Gb performance

Daniel Braniss wrote: On 19 Aug 2015, at 16:00, Rick Macklem rmack...@uoguelph.ca wrote: Hans Petter Selasky wrote: On 08/19/15 09:42, Yonghyeon PYUN wrote: On Wed, Aug 19, 2015 at 09:00:52AM +0200, Hans Petter Selasky wrote: On 08/18/15 23:54, Rick Macklem wrote: Ouch! Yes, I now

Re: ix(intel) vs mlxen(mellanox) 10Gb performance

Daniel Braniss wrote: On Aug 18, 2015, at 12:49 AM, Rick Macklem rmack...@uoguelph.ca wrote: Daniel Braniss wrote: On Aug 17, 2015, at 3:21 PM, Rick Macklem rmack...@uoguelph.ca wrote: Daniel Braniss wrote: On Aug 17, 2015, at 1:41 PM, Christopher Forgeron csforge

Re: ix(intel) vs mlxen(mellanox) 10Gb performance

Hans Petter Selasky wrote: On 08/18/15 14:53, Rick Macklem wrote: If this is just a test machine, maybe you could test with these lines (at about #880) in sys/netinet/tcp_output.c commented out? (It looks to me like this will disable TSO for almost all the NFS writes.) - around line

Re: ix(intel) vs mlxen(mellanox) 10Gb performance

Daniel Braniss wrote: On Aug 18, 2015, at 12:49 AM, Rick Macklem rmack...@uoguelph.ca wrote: Daniel Braniss wrote: On Aug 17, 2015, at 3:21 PM, Rick Macklem rmack...@uoguelph.ca wrote: Daniel Braniss wrote: On Aug 17, 2015, at 1:41 PM, Christopher Forgeron csforge

  1   2   3   4   >