Processed: Re: Bug#795991: /boot/vmlinuz-3.16.0-0.bpo.4-amd64: duplicate request cache is too small for NFS 4.1 servers
Processing commands for cont...@bugs.debian.org: > tags 795991 + wontfix Bug #795991 [src:linux] linux-image-3.16.0-4-amd64: duplicate request cache is too small for NFS 4.1 servers Added tag(s) wontfix. > thanks Stopping processing here. Please contact me if you need assistance. -- 795991: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795991 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#795991: /boot/vmlinuz-3.16.0-0.bpo.4-amd64: duplicate request cache is too small for NFS 4.1 servers
Hi Salvatore Am 01.05.21 um 07:55 schrieb Salvatore Bonaccorso: > > Ack thans for confirming. So either someone tries to bring that issue > again to upstream or alternatively we could then close this bug > marking (and possibly marking it wontfix). > I'm fine with closing and marking wontfix because upstream does so also. Christoph OpenPGP_signature Description: OpenPGP digital signature
Bug#795991: /boot/vmlinuz-3.16.0-0.bpo.4-amd64: duplicate request cache is too small for NFS 4.1 servers
Sorry, please ignore this message. Wrong Bug report. Am 03.05.21 um 11:25 schrieb Christoph Martin: > Hi Salvator, > >> >> is this problem still relevant? >> > > I don't see the reported error messages in Stretch and Buster. > I think the issue is resolve. > > Christoph > OpenPGP_signature Description: OpenPGP digital signature
Bug#795991: /boot/vmlinuz-3.16.0-0.bpo.4-amd64: duplicate request cache is too small for NFS 4.1 servers
Hi Salvator, > > is this problem still relevant? > I don't see the reported error messages in Stretch and Buster. I think the issue is resolve. Christoph OpenPGP_signature Description: OpenPGP digital signature
Bug#795991: /boot/vmlinuz-3.16.0-0.bpo.4-amd64: duplicate request cache is too small for NFS 4.1 servers
Hi Christoph, On Fri, Apr 30, 2021 at 05:32:43PM +0200, Christoph Martin wrote: > > > Am 30.04.21 um 14:32 schrieb Salvatore Bonaccorso: > > > > is this problem still relevant? > > > > I think so. My upstream request was never really considered. > You still have the problem that a kernel-nfs server with only few memory > runs out of sessions with a lot of clients. Ack thans for confirming. So either someone tries to bring that issue again to upstream or alternatively we could then close this bug marking (and possibly marking it wontfix). > > Side note that we would anyway not apply a patch which would not have > > been accepted upstream, likely unless there are very valid reasons. > > > > Yes I also think so. > > We changed to nfs-ganesha as a user level NFS server, which does not > have this restriction. Thanks for this additional comment. Thanks as well for your promt reply back! Regards, Salvatore
Bug#795991: /boot/vmlinuz-3.16.0-0.bpo.4-amd64: duplicate request cache is too small for NFS 4.1 servers
Am 30.04.21 um 14:32 schrieb Salvatore Bonaccorso: > > is this problem still relevant? > I think so. My upstream request was never really considered. You still have the problem that a kernel-nfs server with only few memory runs out of sessions with a lot of clients. > Side note that we would anyway not apply a patch which would not have > been accepted upstream, likely unless there are very valid reasons. > Yes I also think so. We changed to nfs-ganesha as a user level NFS server, which does not have this restriction. Christoph
Processed: Re: Bug#795991: /boot/vmlinuz-3.16.0-0.bpo.4-amd64: duplicate request cache is too small for NFS 4.1 servers
Processing control commands: > tags -1 + moreinfo Bug #795991 [src:linux] linux-image-3.16.0-4-amd64: duplicate request cache is too small for NFS 4.1 servers Added tag(s) moreinfo. -- 795991: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795991 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#795991: /boot/vmlinuz-3.16.0-0.bpo.4-amd64: duplicate request cache is too small for NFS 4.1 servers
Control: tags -1 + moreinfo On Tue, Aug 18, 2015 at 03:30:59PM +0200, Christoph Martin wrote: > Package: src:linux > Version: 3.16.7-ckt11-1+deb8u3~bpo70+1 > Severity: normal > File: /boot/vmlinuz-3.16.0-0.bpo.4-amd64 > > The drc (duplicate request cache) for NFS 4.1 in the vanilla kernel > has a fixed size only depending on the RAM of the machine. > > For example, when setting up a vm which should only serve as a > nfs referral server with 768 MB RAM it could only server about > 20 clients. So it is roughly 32 clients per GB. > > The problem is, that in nfssvc.c the size of drc is calculated with > a shift of NFSD_DRC_SIZE_SHIFT bits from the RAM size. > > I attach a patch for this which I also sent to linux-nfs. > (See http://www.spinics.net/lists/linux-nfs/msg51791.html) > > It implements a module variable to set the size on module load. > > It hope that such a patch can make it into Debian soon. is this problem still relevant? Side note that we would anyway not apply a patch which would not have been accepted upstream, likely unless there are very valid reasons. Regards, Salvatore
Bug#795991: /boot/vmlinuz-3.16.0-0.bpo.4-amd64: duplicate request cache is too small for NFS 4.1 servers
Package: src:linux
Version: 3.16.7-ckt11-1+deb8u3~bpo70+1
Severity: normal
File: /boot/vmlinuz-3.16.0-0.bpo.4-amd64
The drc (duplicate request cache) for NFS 4.1 in the vanilla kernel
has a fixed size only depending on the RAM of the machine.
For example, when setting up a vm which should only serve as a
nfs referral server with 768 MB RAM it could only server about
20 clients. So it is roughly 32 clients per GB.
The problem is, that in nfssvc.c the size of drc is calculated with
a shift of NFSD_DRC_SIZE_SHIFT bits from the RAM size.
I attach a patch for this which I also sent to linux-nfs.
(See http://www.spinics.net/lists/linux-nfs/msg51791.html)
It implements a module variable to set the size on module load.
It hope that such a patch can make it into Debian soon.
Yours
Christoph
-- System Information:
Debian Release: 7.8
APT prefers oldstable-updates
APT policy: (700, 'oldstable-updates'), (700, 'oldstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.7-ckt9 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Versions of packages linux-image-3.16.0-0.bpo.4-amd64 depends on:
ii debconf [debconf-2.0] 1.5.49
ii initramfs-tools0.115~bpo70+1
ii kmod 9-3
ii linux-base 3.5
ii module-init-tools 9-3
Versions of packages linux-image-3.16.0-0.bpo.4-amd64 recommends:
ii firmware-linux-free 3.2
ii irqbalance 1.0.3-3
Versions of packages linux-image-3.16.0-0.bpo.4-amd64 suggests:
pn debian-kernel-handbook none
ii grub-pc 1.99-27+deb7u2
pn linux-doc-3.16 none
Versions of packages linux-image-3.16.0-0.bpo.4-amd64 is related to:
pn firmware-atherosnone
pn firmware-bnx2 none
pn firmware-bnx2x none
pn firmware-brcm80211 none
pn firmware-intelwimax none
pn firmware-ipw2x00none
pn firmware-ivtv none
pn firmware-iwlwifinone
pn firmware-libertas none
pn firmware-linux none
pn firmware-linux-nonfree none
pn firmware-myricomnone
pn firmware-netxen none
pn firmware-qlogic none
pn firmware-ralink none
pn firmware-realteknone
pn xen-hypervisor none
-- debconf information:
linux-image-3.16.0-0.bpo.4-amd64/postinst/depmod-error-initrd-3.16.0-0.bpo.4-amd64:
false
linux-image-3.16.0-0.bpo.4-amd64/postinst/mips-initrd-3.16.0-0.bpo.4-amd64:
linux-image-3.16.0-0.bpo.4-amd64/prerm/removing-running-kernel-3.16.0-0.bpo.4-amd64:
true
--- linux-source-3.16/fs/nfsd/nfssvc.c 2015-03-30 12:09:09.0 +0200
+++ linux-source-3.16.nfsd/fs/nfsd/nfssvc.c 2015-06-17 09:28:37.880443867 +0200
@@ -359,11 +359,19 @@ void nfsd_reset_versions(void)
* For now this is a #defined shift which could be under admin control
* in the future.
*/
+
+static ulong drc_size = 0;
+module_param(drc_size, ulong, 0444);
+MODULE_PARM_DESC(drc_size,
+ size of NFSv4.1 DRC cache memory (default and minimum: free_buffer_size 10));
+
static void set_max_drc(void)
{
#define NFSD_DRC_SIZE_SHIFT 10
- nfsd_drc_max_mem = (nr_free_buffer_pages()
- NFSD_DRC_SIZE_SHIFT) * PAGE_SIZE;
+ nfsd_drc_max_mem = max(drc_size,
+ (nr_free_buffer_pages()
+ NFSD_DRC_SIZE_SHIFT) * PAGE_SIZE);
+ drc_size = nfsd_drc_max_mem;
nfsd_drc_mem_used = 0;
spin_lock_init(nfsd_drc_lock);
dprintk(%s nfsd_drc_max_mem %lu \n, __func__, nfsd_drc_max_mem);
