From: Daire Byrne <daire@dneg.com>
To: Richard Weinberger <richard@nod.at>
Cc: bfields <bfields@fieldses.org>,
linux-nfs <linux-nfs@vger.kernel.org>,
luis turcitu <luis.turcitu@appsbroker.com>,
chris chilvers <chris.chilvers@appsbroker.com>,
david young <david.young@appsbroker.com>,
david <david@sigma-star.at>,
david oberhollenzer <david.oberhollenzer@sigma-star.at>
Subject: Re: Improving NFS re-export
Date: Tue, 21 Dec 2021 14:30:45 +0000 [thread overview]
Message-ID: <CAPt2mGM5jJNu_O=pjvU4UEYZ7L9pcunGedVmFP1h+J4QoMLPUg@mail.gmail.com> (raw)
In-Reply-To: <763412597.153709.1639087404752.JavaMail.zimbra@nod.at>
On Thu, 9 Dec 2021 at 22:03, Richard Weinberger <richard@nod.at> wrote:
>
> I see. That way we could get rid of file handle wrapping but loose the
> NFS clinet inode cache on the re-exporting server, I think.
As an avid user of re-exporting over the WAN, we do like to be able to
selectively cache as much of the metadata lookups as possible
(actimeo=3600, vfs_cache_pressure=1).
I'm not sure if losing the re-export server's client inode cache would
effect that ability?
And on the subject of the "proxy" server and a server per export; if
like us, you have 30 servers or mountpoints to re-export but you might
only actively use 5-10 of those at any one time, so it is more
resource efficient (CPU, RAM, fscache storage) to use a single
re-export server for more than one mountpoint re-export. But in the
proxy case, maybe the same thing could be achieved with a
containerised knfsd with all the proxy servers running on the same
server?
I'm not sure if you could have shared storage and have multiple
fs-cache/cachefilesd in containers though.
Either way, I'm interested to see what you come up with. Always happy
to test new variations on re-exporting.
Daire
next prev parent reply other threads:[~2021-12-21 14:31 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-09 21:05 Improving NFS re-export Richard Weinberger
2021-12-09 21:41 ` J. Bruce Fields
2021-12-09 22:03 ` Richard Weinberger
2021-12-21 14:30 ` Daire Byrne [this message]
2021-12-21 17:21 ` bfields
2021-12-21 21:39 ` Richard Weinberger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAPt2mGM5jJNu_O=pjvU4UEYZ7L9pcunGedVmFP1h+J4QoMLPUg@mail.gmail.com' \
--to=daire@dneg.com \
--cc=bfields@fieldses.org \
--cc=chris.chilvers@appsbroker.com \
--cc=david.oberhollenzer@sigma-star.at \
--cc=david.young@appsbroker.com \
--cc=david@sigma-star.at \
--cc=linux-nfs@vger.kernel.org \
--cc=luis.turcitu@appsbroker.com \
--cc=richard@nod.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.