Re: [arch-general] NFS "updates"?

2020-04-27 Thread Hauke Fath
On Mon, 27 Apr 2020 19:25:59 +0100, Leonidas Spyropoulos via 
arch-general wrote:
> On 27/04/20, Hauke Fath wrote:
>> Re-reading, this is an Arch decision -- what is the rationale? Can 
>> anybody point me to a related discussion?
> 
> It's not, it just defaults to "Y", 

-- which requires building your own kernel to change, right?

> see patch in
> 
https://github.com/archlinux/linux/commit/b24ee6c64ca785739b3ef8d95fd6becaad1bde39
> 
> There's also a bit of explanation if it's useful

Yes, it is - actually, nfs(5) has a much longer explanation, as well as 
a viable workaround: Shorten the udp fragment reassembly timeout on 
fast networks.

On Mon, 27 Apr 2020 20:12:17 +0200, Markus Schaaf via arch-general 
wrote:
>> It's a kernel configuration which is introduced with 5.6 kernel. In my
>> CONFIG_NFS_DISABLE_UDP_SUPPORT=y
> 
> Wow! I'd say udp is used a lot with nfsvers=3. That will break many nfs3
> deployments.

This.

I (and my users) certainly would appreciate if the decision could be 
reconsidered.

Cheerio,
Hauke

-- 
 The ASCII Ribbon CampaignHauke Fath
() No HTML/RTF in emailInstitut für Nachrichtentechnik
/\ No Word docs in email TU Darmstadt
 Respect for open standards  Ruf +49-6151-16-21344


Re: [arch-general] NFS "updates"?

2020-04-27 Thread Leonidas Spyropoulos via arch-general
On 27/04/20, Hauke Fath wrote:
> Re-reading, this is an Arch decision -- what is the rationale? Can 
> anybody point me to a related discussion?

It's not, it just defaults to "Y", see patch in
https://github.com/archlinux/linux/commit/b24ee6c64ca785739b3ef8d95fd6becaad1bde39

There's also a bit of explanation if it's useful

Cheers,

-- 
Leonidas Spyropoulos

A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?


Re: [arch-general] NFS "updates"?

2020-04-27 Thread Hauke Fath
On Mon, 27 Apr 2020 19:00:32 +0100, Leonidas Spyropoulos via 
arch-general wrote:
> $ zcat /proc/config.gz | grep NFS_DISABLE
> CONFIG_NFS_DISABLE_UDP_SUPPORT=y
> 
> The change happened with commit
> 


Re-reading, this is an Arch decision -- what is the rationale? Can 
anybody point me to a related discussion? And why does the kernel end 
up talking about nfsv4, as if it hit 
?

Cheerio,
Hauke

-- 
 The ASCII Ribbon CampaignHauke Fath
() No HTML/RTF in emailInstitut für Nachrichtentechnik
/\ No Word docs in email TU Darmstadt
 Respect for open standards  Ruf +49-6151-16-21344


Re: [arch-general] NFS "updates"?

2020-04-27 Thread Hauke Fath
On Mon, 27 Apr 2020 19:00:32 +0100, Leonidas Spyropoulos via 
arch-general wrote:

Thanks for the note!

> It's a kernel configuration which is introduced with 5.6 kernel. In my
> kernel which is 5.6.7-arch1-1
> 
> $ zcat /proc/config.gz | grep NFS_DISABLE
> CONFIG_NFS_DISABLE_UDP_SUPPORT=y

Meaning this is an upstream change? Might have been worth an entry on 
www.archlinux.org/news/... 

So I guess the short-term fix is to switch to an LTS kernel, and 
mid-term I will have to get into building my own kernels?

Cheerio,
Hauke

-- 
 The ASCII Ribbon CampaignHauke Fath
() No HTML/RTF in emailInstitut für Nachrichtentechnik
/\ No Word docs in email TU Darmstadt
 Respect for open standards  Ruf +49-6151-16-21344


Re: [arch-general] NFS "updates"?

2020-04-27 Thread Markus Schaaf via arch-general
Am 27.04.20 um 20:00 schrieb Leonidas Spyropoulos via arch-general:

> It's a kernel configuration which is introduced with 5.6 kernel. In my
> CONFIG_NFS_DISABLE_UDP_SUPPORT=y

Wow! I'd say udp is used a lot with nfsvers=3. That will break many nfs3
deployments.


Re: [arch-general] NFS "updates"?

2020-04-27 Thread Leonidas Spyropoulos via arch-general
On 27/04/20, Hauke Fath wrote:
> On Mon, 27 Apr 2020 19:19:21 +0200, Hauke Fath wrote:
> > I'll give some of the configuration.
> 
> FTR, the borken system's kernel is
> 
> Linux version 5.6.7-arch1-1 (linux@archlinux) (gcc version 9.3.0 (Arch 
> Linux 9.3.0-1)) #1 SMP PREEMPT Thu, 23 Apr 2020 09:13:56 +
> 
> while the working system has
> 
> Linux version 5.5.8-arch1-1 (linux@archlinux) (gcc version 9.2.1 
> 20200130 (Arch Linux 9.2.1+20200130-2)) #1 SMP PREEMPT Fri, 06 Mar 2020 
> 00:57:33 +
> 
> Cheerio,
> Hauke
> 
Hi Hauke,

It's a kernel configuration which is introduced with 5.6 kernel. In my
kernel which is 5.6.7-arch1-1

$ zcat /proc/config.gz | grep NFS_DISABLE
CONFIG_NFS_DISABLE_UDP_SUPPORT=y

The change happened with commit
https://git.archlinux.org/svntogit/packages.git/commit/trunk/config?h=packages/linux&id=3734fe98a51ca7e776052cdabc80be9885b7d40d

Cheers,

-- 
Leonidas Spyropoulos

A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?


Re: [arch-general] NFS "updates"?

2020-04-27 Thread Hauke Fath
On Mon, 27 Apr 2020 19:19:21 +0200, Hauke Fath wrote:
> I'll give some of the configuration.

FTR, the borken system's kernel is

Linux version 5.6.7-arch1-1 (linux@archlinux) (gcc version 9.3.0 (Arch 
Linux 9.3.0-1)) #1 SMP PREEMPT Thu, 23 Apr 2020 09:13:56 +

while the working system has

Linux version 5.5.8-arch1-1 (linux@archlinux) (gcc version 9.2.1 
20200130 (Arch Linux 9.2.1+20200130-2)) #1 SMP PREEMPT Fri, 06 Mar 2020 
00:57:33 +

Cheerio,
Hauke

-- 
 The ASCII Ribbon CampaignHauke Fath
() No HTML/RTF in emailInstitut für Nachrichtentechnik
/\ No Word docs in email TU Darmstadt
 Respect for open standards  Ruf +49-6151-16-21344


Re: [arch-general] NFS "updates"?

2020-04-27 Thread Hauke Fath
On Mon, 27 Apr 2020 17:23:39 +0200, Markus Schaaf via arch-general 
wrote:
> Am 27.04.20 um 16:51 schrieb Hauke Fath:
> 
>> NFSV4: Unsupported transport protocol udp
> 
> Have you tried vers=3 in mount options?

Thanks for the reply. I'll give some of the configuration.

(1) autofs config is distributed through nis:

% grep '^[/]' /etc/automount/auto.master
/home   auto.home   
-udp,nfsvers=3,resvport,nolock,noacl,grpid,retrans=5,rsize=16384,wsize=16384,rw,hard,intr
/misc   auto.misc   
-udp,nfsvers=3,resvport,grpid,local_lock=none,retrans=5,rw,hard,intr
%

(2) The client autofs setup:

%  grep -v '^#' /etc/autofs/autofs.conf
[ autofs ]
timeout = 300
browse_mode = no
[ amd ]
dismount_interval = 300
%

This setup has worked for years, and continues to work after rolling 
back to the 2020-03-09 state. There is no nfsv4 anywhere in sight: The 
server setup disables it, and wherever I can specify nfsv3 on the 
client, I have.

From the journal:

[...]
Apr 27 16:27:20 Ankogel.nt.e-technik.tu-darmstadt.de automount[567]: 
attempting to mount entry /home/XXX
Apr 27 16:27:20 Ankogel.nt.e-technik.tu-darmstadt.de kernel: RPC: 
Registered named UNIX socket transport module.
Apr 27 16:27:20 Ankogel.nt.e-technik.tu-darmstadt.de kernel: RPC: 
Registered udp transport module.
Apr 27 16:27:20 Ankogel.nt.e-technik.tu-darmstadt.de kernel: RPC: 
Registered tcp transport module.
Apr 27 16:27:20 Ankogel.nt.e-technik.tu-darmstadt.de kernel: RPC: 
Registered tcp NFSv4.1 backchannel transport module.
Apr 27 16:27:20 Ankogel.nt.e-technik.tu-darmstadt.de kernel: FS-Cache: 
Netfs 'nfs' registered for caching
Apr 27 16:27:20 Ankogel.nt.e-technik.tu-darmstadt.de kernel: *** 
VALIDATE nfs ***
Apr 27 16:27:20 Ankogel.nt.e-technik.tu-darmstadt.de kernel: *** 
VALIDATE nfs4 ***
Apr 27 16:27:20 Ankogel.nt.e-technik.tu-darmstadt.de kernel: NFSv4: 
Unsupported transport protocol udp
Apr 27 16:27:20 Ankogel.nt.e-technik.tu-darmstadt.de automount[567]: >> 
mount.nfs: an incorrect mount option was specified
Apr 27 16:27:20 Ankogel.nt.e-technik.tu-darmstadt.de automount[567]: 
mount(nfs): nfs: mount failure NFSSERVER:/u/homes/XXX on /home/XXX
Apr 27 16:27:20 Ankogel.nt.e-technik.tu-darmstadt.de automount[567]: 
failed to mount /home/XXX
[...]

AFAICS, the kernel has no business "validating" an nfsv4 mount, because 
none has been asked for.

The 2020-03-09 setup:

[...]
Apr 27 18:57:11 Ankogel.nt.e-technik.tu-darmstadt.de automount[546]: 
attempting to mount entry /home/XXX
Apr 27 18:57:11 Ankogel.nt.e-technik.tu-darmstadt.de kernel: RPC: 
Registered named UNIX socket transport module.
Apr 27 18:57:11 Ankogel.nt.e-technik.tu-darmstadt.de kernel: RPC: 
Registered udp transport module.
Apr 27 18:57:11 Ankogel.nt.e-technik.tu-darmstadt.de kernel: RPC: 
Registered tcp transport module.
Apr 27 18:57:11 Ankogel.nt.e-technik.tu-darmstadt.de kernel: RPC: 
Registered tcp NFSv4.1 backchannel transport module.
Apr 27 18:57:11 Ankogel.nt.e-technik.tu-darmstadt.de kernel: FS-Cache: 
Netfs 'nfs' registered for caching
Apr 27 18:57:11 Ankogel.nt.e-technik.tu-darmstadt.de automount[546]: 
mounted /home/XXX
[...]

From what I can see, either I missed some obscure new configuration 
that overrides the automounter's explicit mount options. Or, I hit a 
kernel bug.

Cheerio,
Hauke

-- 
 The ASCII Ribbon CampaignHauke Fath
() No HTML/RTF in emailInstitut für Nachrichtentechnik
/\ No Word docs in email TU Darmstadt
 Respect for open standards  Ruf +49-6151-16-21344


Re: [arch-general] NFS "updates"?

2020-04-27 Thread Markus Schaaf via arch-general
Am 27.04.20 um 16:51 schrieb Hauke Fath:

> NFSV4: Unsupported transport protocol udp

Have you tried vers=3 in mount options?


[arch-general] NFS "updates"?

2020-04-27 Thread Hauke Fath
All,

we have a group of Arch desktop clients that mount their user homes and 
group shares through nfsv3 over udp from an OmniOS server.

After today's update (the last one was on 9 Mar) the machine will not 
nfs-mount, complaining about illegal udp, grpid, int mount options, and 
the kernel spits out a

NFSV4: Unsupported transport protocol udp

although nothing on this installation anywhere ever has used nfsv4 
until now, and /etc/default/autofs explicitly specifies nfsv3. Editing 
/etc/nfsmount.conf (which was in default state until now) accordingly 
did not make a difference.

I couldn't find any nfs related Arch news items.

What did I miss?

Cheerio,
Hauke


-- 
 The ASCII Ribbon CampaignHauke Fath
() No HTML/RTF in email Institut für Nachrichtentechnik
/\ No Word docs in email TU Darmstadt
 Respect for open standards  Ruf +49-6151-16-21344