Date: Tue, 24 Dec 2019 03:02:17 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: Richard P Mackerras <mack63richard@gmail.com>, Adam McDougall <mcdouga9@egr.msu.edu> Cc: "freebsd-stable@freebsd.org" <freebsd-stable@freebsd.org> Subject: Re: nfs lockd errors after NetApp software upgrade. Message-ID: <YQBPR0101MB142781B3EF4F85A1A6ED2AE5DD290@YQBPR0101MB1427.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <CAGfybS-a6n=Pkz8iBPj7BQ3=DbFoZRFENmy2wK3B=HzHm5dVWg@mail.gmail.com> References: <EBC4AD74-EC62-4C67-AB93-1AA91F662AAC@cs.huji.ac.il> <YQBPR0101MB1427411AFE335E869B9CF022DD530@YQBPR0101MB1427.CANPRD01.PROD.OUTLOOK.COM> <0121E289-D2AE-44BA-ADAC-4814CAEE676F@cs.huji.ac.il> <CAGfybS-3Rvs57=oGFEfii_9a=aWxPr6dEq1Y1LqHbLXK1ZKmXA@mail.gmail.com> <YQBPR0101MB1427F9BE658B9A46C7E08335DD520@YQBPR0101MB1427.CANPRD01.PROD.OUTLOOK.COM> <854B6E5A-C6BC-44B3-A656-FC9B8EF19881@cs.huji.ac.il> <YQBPR0101MB1427F445F1F1EAF382E5131ADD520@YQBPR0101MB1427.CANPRD01.PROD.OUTLOOK.COM> <8770BD0D-4B72-431A-B4F5-A29D4DBA03B1@cs.huji.ac.il> <b1182bbf-fd0b-a23d-1cc4-ddf9513bcb2e@egr.msu.edu> <YQBPR0101MB1427CE52BBA32A888443BFB4DD2D0@YQBPR0101MB1427.CANPRD01.PROD.OUTLOOK.COM> <8A78F67B-C244-45CF-B9BF-D7062669B33B@cs.huji.ac.il> <YQBPR0101MB1427C9D4CF8918F10B6FD400DD2C0@YQBPR0101MB1427.CANPRD01.PROD.OUTLOOK.COM> <AE8F5D6B-E7DA-4AB9-B909-7D362A6A406B@cs.huji.ac.il> <YQBPR0101MB14276E7F9C127374C3E36952DD2F0@YQBPR0101MB1427.CANPRD01.PROD.OUTLOOK.COM> <a33ad299-9ec6-0dc9-0926-32f20cb130c5@egr.msu.edu>, <CAGfybS-a6n=Pkz8iBPj7BQ3=DbFoZRFENmy2wK3B=HzHm5dVWg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Richard P Mackerras wrote:=0A= >Hi,=0A= >=0A= >We had some bully type workloads emerge when we moved a lot of block=0A= >storage from old XIV to new all flash 3PAR. I wonder if your IMAP issue=0A= >might have emerged just because suddenly there was the opportunity with al= l=0A= >flash. QOS is good on 9.x ONTAP. If anyone says it=92s not then they last= =0A= >looked on 8.x. So I suggest you QOS the IMAP workload.=0A= >=0A= > Nobody should be using UDP with NFS unless they have a very specific set= =0A= >of circumstances. TCP was a real step forward.=0A= Well, I can't argue with this, considering I did the first working implemen= tation=0A= of NFS over TCP. It was actually Mike Karels that suggested I try doing so,= =0A= There's a paper in a very old Usenix Conference Proceedings, but it is so o= ld=0A= that it isn't on the Usenix web page (around 1988 in Denver, if I recall). = I don't=0A= even have a copy myself, although I was the author.=0A= =0A= Now, having said that, I must note that the Network Lock Manager (NLM) and= =0A= Network Status Monitor (NSM) were not NFS. They were separate stateful=0A= protocols (poorly designed imho) that Sun never published.=0A= =0A= NFS as Sun designed it (NFSv2 and NFSv3) were "stateless server" protocols,= =0A= so that they could work reliably without server crash recovery.=0A= However, the NLM was inherently stateful, since it was dealing with file lo= cks.=0A= =0A= So, you can't really lump the NLM with NFS (and you should avoid use of the= =0A= NLM over any transport imho).=0A= =0A= NFSv4 tackled the difficult problem of having a "stateful server" and crash= recovery,=0A= which resulted in a much more complex protocol (compare the size of RFC-181= 3=0A= vs RFC-5661 to get some idea of this).=0A= =0A= rick=0A= =0A= Cheers=0A= =0A= Richard=0A= _______________________________________________=0A= freebsd-stable@freebsd.org mailing list=0A= https://lists.freebsd.org/mailman/listinfo/freebsd-stable=0A= To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"= =0A=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YQBPR0101MB142781B3EF4F85A1A6ED2AE5DD290>