All of lore.kernel.org
 help / color / mirror / Atom feed
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
> 


  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 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.