Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.kernel > #70939 > unrolled thread
| Started by | Salvatore Bonaccorso <carnil@debian.org> |
|---|---|
| First post | 2021-04-30 14:40 +0200 |
| Last post | 2021-05-03 11:40 +0200 |
| Articles | 5 — 2 participants |
Back to article view | Back to linux.debian.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Bug#795991: /boot/vmlinuz-3.16.0-0.bpo.4-amd64: duplicate request cache is too small for NFS 4.1 servers Salvatore Bonaccorso <carnil@debian.org> - 2021-04-30 14:40 +0200
Bug#795991: /boot/vmlinuz-3.16.0-0.bpo.4-amd64: duplicate request cache is too small for NFS 4.1 servers Christoph Martin <martin@uni-mainz.de> - 2021-04-30 17:50 +0200
Bug#795991: /boot/vmlinuz-3.16.0-0.bpo.4-amd64: duplicate request cache is too small for NFS 4.1 servers Salvatore Bonaccorso <carnil@debian.org> - 2021-05-01 08:00 +0200
Bug#795991: /boot/vmlinuz-3.16.0-0.bpo.4-amd64: duplicate request cache is too small for NFS 4.1 servers Christoph Martin <martin@uni-mainz.de> - 2021-05-03 12:00 +0200
Bug#795991: /boot/vmlinuz-3.16.0-0.bpo.4-amd64: duplicate request cache is too small for NFS 4.1 servers Christoph Martin <martin@uni-mainz.de> - 2021-05-03 11:40 +0200
| From | Salvatore Bonaccorso <carnil@debian.org> |
|---|---|
| Date | 2021-04-30 14:40 +0200 |
| Subject | Bug#795991: /boot/vmlinuz-3.16.0-0.bpo.4-amd64: duplicate request cache is too small for NFS 4.1 servers |
| Message-ID | <C9AB4-7ub-11@gated-at.bofh.it> |
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
[toc] | [next] | [standalone]
| From | Christoph Martin <martin@uni-mainz.de> |
|---|---|
| Date | 2021-04-30 17:50 +0200 |
| Message-ID | <C9DyV-L4-5@gated-at.bofh.it> |
| In reply to | #70939 |
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
[toc] | [prev] | [next] | [standalone]
| From | Salvatore Bonaccorso <carnil@debian.org> |
|---|---|
| Date | 2021-05-01 08:00 +0200 |
| Message-ID | <C9QPv-sk-1@gated-at.bofh.it> |
| In reply to | #70962 |
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
[toc] | [prev] | [next] | [standalone]
| From | Christoph Martin <martin@uni-mainz.de> |
|---|---|
| Date | 2021-05-03 12:00 +0200 |
| Message-ID | <CaDwS-4bI-7@gated-at.bofh.it> |
| In reply to | #71002 |
[Multipart message — attachments visible in raw view] — view raw
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
[toc] | [prev] | [next] | [standalone]
| From | Christoph Martin <martin@uni-mainz.de> |
|---|---|
| Date | 2021-05-03 11:40 +0200 |
| Message-ID | <CaDdv-45a-3@gated-at.bofh.it> |
| In reply to | #70939 |
[Multipart message — attachments visible in raw view] — view raw
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 >
[toc] | [prev] | [standalone]
Back to top | Article view | linux.debian.kernel
csiph-web