From: Steve Dickson <steved@redhat.com>
To: "J. Bruce Fields" <bfields@fieldses.org>,
Richard Weinberger <richard@nod.at>
Cc: linux-nfs@vger.kernel.org, david@sigma-star.at,
luis.turcitu@appsbroker.com, david.young@appsbroker.com,
david.oberhollenzer@sigma-star.at,
trond.myklebust@hammerspace.com, anna.schumaker@netapp.com,
chris.chilvers@appsbroker.com
Subject: Re: [PATCH 0/5] nfs-utils: Improving NFS re-exports
Date: Mon, 2 May 2022 18:46:59 -0400 [thread overview]
Message-ID: <929b0a83-7a10-8a26-941f-3819c957ba7a@redhat.com> (raw)
In-Reply-To: <20220502161713.GI30550@fieldses.org>
On 5/2/22 12:17 PM, J. Bruce Fields wrote:
> On Mon, May 02, 2022 at 10:50:40AM +0200, Richard Weinberger wrote:
>> This is the first non-RFC iteration of the NFS re-export
>> improvement series for nfs-utils.
>> While the kernel side[0] didn't change at all and is still small,
>> the userspace side saw much more changes.
>>
>> The core idea is adding new export option: reeport=
>> Using reexport= it is possible to mark an export entry in the exports
>> file explicitly as NFS re-export and select a strategy how unique
>> identifiers should be provided.
>> Currently two strategies are supported, "auto-fsidnum" and
>> "predefined-fsidnum", both use a SQLite database as backend to keep
>> track of generated ids.
>> For a more detailed description see patch "exports: Implement new export option reexport=".
>> I choose SQLite because nfs-utils already uses it and using SQL ids can nicely
>> generated and maintained. It will also scale for large setups where the amount
>> of subvolumes is high.
>>
>> Beside of id generation this series also addresses the reboot problem.
>> If the re-exporting NFS server reboots, uncovered NFS subvolumes are not yet
>> mounted and file handles become stale.
>> Now mountd/exportd keeps track of uncovered subvolumes and makes sure they get
>> uncovered while nfsd starts.
>>
>> The whole set of features is currently opt-in via --enable-reexport.
>
> Can we remove that option before upstreaming?
>
> For testing purposes it may makes sense to be able to turn the new code
> on and off quickly. But for something we're really going to support,
> it's just another hurdle for users to jump through, and another case we
> probably won't remember to test. The export options themselves should
> be enough configuration.
>
> Anyway, basically sounds reasonable to me. I'll try to give it a proper
> review sometime, feel free to bug me if I don't get to it in a week or
> so.
How about --disable-reexport? So it is on by default to help testing
but if there are issues we can turn it off...
steved.
>
> --b.
>
>
>> I'm also not sure about the rearrangement of the reexport code,
>> currently it is a helper library.
>>
>> A typical export entry on a re-exporting server looks like:
>> /nfs *(rw,no_root_squash,no_subtree_check,crossmnt,reexport=auto-fsidnum)
>> reexport=auto-fsidnum will automatically assign an fsid= to /nfs and all
>> uncovered subvolumes.
>>
>> Richard Weinberger (5):
>> Implement reexport helper library
>> exports: Implement new export option reexport=
>> export: Implement logic behind reexport=
>> export: Avoid fsid= conflicts
>> reexport: Make state database location configurable
>>
>> [0] https://git.kernel.org/pub/scm/linux/kernel/git/rw/misc.git/log/?h=nfs_reexport_clean
>>
>> configure.ac | 12 ++
>> nfs.conf | 3 +
>> support/Makefile.am | 4 +
>> support/export/Makefile.am | 2 +
>> support/export/cache.c | 71 ++++++-
>> support/export/export.c | 27 ++-
>> support/include/nfslib.h | 1 +
>> support/nfs/Makefile.am | 1 +
>> support/nfs/exports.c | 68 +++++++
>> support/reexport/Makefile.am | 6 +
>> support/reexport/reexport.c | 354 +++++++++++++++++++++++++++++++++
>> support/reexport/reexport.h | 39 ++++
>> systemd/Makefile.am | 4 +
>> systemd/nfs-server-generator.c | 14 +-
>> systemd/nfs.conf.man | 6 +
>> utils/exportd/Makefile.am | 8 +-
>> utils/exportd/exportd.c | 5 +
>> utils/exportfs/Makefile.am | 6 +
>> utils/exportfs/exportfs.c | 21 +-
>> utils/exportfs/exports.man | 31 +++
>> utils/mount/Makefile.am | 7 +
>> utils/mountd/Makefile.am | 6 +
>> utils/mountd/mountd.c | 1 +
>> utils/mountd/svc_run.c | 6 +
>> 24 files changed, 690 insertions(+), 13 deletions(-)
>> create mode 100644 support/reexport/Makefile.am
>> create mode 100644 support/reexport/reexport.c
>> create mode 100644 support/reexport/reexport.h
>>
>> --
>> 2.31.1
>
next prev parent reply other threads:[~2022-05-02 22:47 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-02 8:50 [PATCH 0/5] nfs-utils: Improving NFS re-exports Richard Weinberger
2022-05-02 8:50 ` [PATCH 1/5] Implement reexport helper library Richard Weinberger
2022-05-10 13:32 ` Steve Dickson
2022-05-10 13:48 ` Chuck Lever III
2022-05-10 13:59 ` Richard Weinberger
2022-05-10 14:04 ` Steve Dickson
2022-05-10 14:17 ` Chuck Lever III
2022-05-10 20:08 ` Steve Dickson
2022-05-10 20:32 ` Richard Weinberger
2022-05-10 20:37 ` Chuck Lever III
2022-05-02 8:50 ` [PATCH 2/5] exports: Implement new export option reexport= Richard Weinberger
2022-05-10 14:32 ` Steve Dickson
2022-05-10 16:06 ` Richard Weinberger
2022-05-10 19:26 ` Steve Dickson
2022-05-02 8:50 ` [PATCH 3/5] export: Implement logic behind reexport= Richard Weinberger
2022-05-02 8:50 ` [PATCH 4/5] export: Avoid fsid= conflicts Richard Weinberger
2022-05-02 8:50 ` [PATCH 5/5] reexport: Make state database location configurable Richard Weinberger
2022-05-02 16:17 ` [PATCH 0/5] nfs-utils: Improving NFS re-exports J. Bruce Fields
2022-05-02 22:46 ` Steve Dickson [this message]
2022-05-03 0:00 ` Chuck Lever III
2022-05-23 7:53 ` Richard Weinberger
2022-05-23 14:25 ` Chuck Lever III
2022-05-23 14:29 ` bfields
2022-05-23 14:31 ` bfields
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=929b0a83-7a10-8a26-941f-3819c957ba7a@redhat.com \
--to=steved@redhat.com \
--cc=anna.schumaker@netapp.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 \
--cc=trond.myklebust@hammerspace.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).