Yes, it makes sense while creating for sure. Someone needs to remember the
exportid while changing an entry that was created before. So I added
exportid and pseudo for now. We can add anything later. "export export_id
14" and "export pseudo /root/exp1" are valid specifications now
On Mar 6, 2017 6:30 PM, "Daniel Gryniewicz" <d...@redhat.com> wrote:
> Isn't export_id the only actual always-required unique key? Maybe just
> use that?
>
> Daniel
>
> On 03/05/2017 11:39 PM, Malahal Naineni wrote:
> > Posted a patch that works at gerritio. It just creats blocks and key
> > value pairs without checking if they constitute a valid ganesha config
> > block. Currently, "export" block takes "pseudo value" and "client
> > block takes "clients-value" as additional arguments. pseudo may not be
> > used in NFSv3 only environments (not sure about 9P).
> >
> > I am thinking to support "pseudo", "path" or "export_id" as well. So
> > to change an export block that has export id as 16, one would do
> > "ganesha_conf set export export_id 16 --param1 value1 --param2
> > value2". If one wants to use pseudo instead, it can be done as
> > "ganesha_conf set export pseudo /nfsroot/spath1 value1 --param2 value2"
> >
> > I am thinking of allowing "export_id", "pseudo" and "path" keys for
> > "export" block identification. We only use "clients" for the client
> > block, but to be consistent with the export block, we will have
> > "ganesha_conf export export_id 16 client clients 192.168.1.0 --param1
> > --value" to change the corresponding "client" block.
> >
> > Any suggestions or issues with this approach?
> >
> > Regards, Malahal.
> >
> > On Mon, Feb 27, 2017 at 2:45 PM, Dominique Martinet
> > <dominique.marti...@cea.fr> wrote:
> >> Malahal Naineni wrote on Sat, Feb 25, 2017 at 03:33:17PM +0530:
> >>> - All config is in blocks
> >>> - Most blocks are unique with their tag names
> >>> - exceptions: "export" and "client" blocks.
> >>> - "export" is unique by "path" value
> >>
> >> More like unique by pseudo path; path can be identical for various
> >> reasons (e.g. exporting the same backend multiple times with different
> >> options)
> >>
> >>> - "client" is unique by "clients" value with in the export block.
> >>> - Log blocks have few subblocks.
> >>
> >> export can also have an arbitrary number of sub-blocks (for FSAL and
> >> stackable FSALs); I think the syntax here should be generic enough and
> >> recursively handled e.g. maybe
> >> ganesha_config set blockname.subblock[.subblock[...]] key value
> >>
> >> --
> >> Dominique
> >
> > ------------------------------------------------------------
> ------------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> > _______________________________________________
> > Nfs-ganesha-devel mailing list
> > Nfs-ganesha-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
> >
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
