> On May 23, 2022, at 3:53 AM, Richard Weinberger <richard@xxxxxx> wrote: > > Bruce, > > ----- Ursprüngliche Mail ----- >> Von: "bfields" <bfields@xxxxxxxxxxxx> >>> The whole set of features is currently opt-in via --enable-reexport. >> >> Can we remove that option before upstreaming? > > What is the final resolution regarding this option? > I can think of embedded/memory constraint systems where the dependency on SQLite > is not wanted. > > On the other hand, with my latest patch, the plugin interface, the could be solved > too. > >> 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. > > *kind ping* :-) > > Please also don't forget the kernel side of this work. It is small but still needed. > See: https://lore.kernel.org/linux-nfs/20220110184419.27665-1-richard@xxxxxx/ > or > https://git.kernel.org/pub/scm/linux/kernel/git/rw/misc.git/log/?h=nfs_reexport_clean In his review comments, Bruce asked if testing with NFSv4 has been done. Also, can an idle client allow the re-export server to unmount an automounted export? Once you have NFSv4 results, the kernel patches need to be posted again with Cc: linux-fsdevel@xxxxxxxxxxxxxxx and autofs@xxxxxxxxxxxxxxx > Since the kernel changes don't change the ABI, it should not really matter which part > is merged first. Kernel or userspace. The only important part is stating the right > kernel version in the nfs-utils manpages. > > Thanks, > //richard -- Chuck Lever
