Re: [PATCH v2 3/5] libceph: crush_location infrastructure

[Ilya Dryomov <idryomov@gmail.com>]

On Sun, May 31, 2020 at 3:27 PM Jeff Layton <jlayton@kernel.org> wrote:
>
> On Sat, 2020-05-30 at 17:34 +0200, Ilya Dryomov wrote:
> > Allow expressing client's location in terms of CRUSH hierarchy as
> > a set of (bucket type name, bucket name) pairs.  The userspace syntax
> > "crush_location = key1=value1 key2=value2" is incompatible with mount
> > options and needed adaptation.  Key-value pairs are separated by '|'
> > and we use ':' instead of '=' to separate keys from values.  So for:
> >
> >   crush_location = host=foo rack=bar
> >
> > one would write:
> >
> >   crush_location=host:foo|rack:bar
> >
> > As in userspace, "multipath" locations are supported, so indicating
> > locality for parallel hierarchies is possible:
> >
> >   crush_location=rack:foo1|rack:foo2|datacenter:bar
> >
>
> This looks much nicer.
>
> The only caveat I have is that using '|' means that you'll need to quote
> or escape the option string on the command line or in shell scripts
> (lest the shell consider it a pipeline directive).
>
> It's hard to find ascii special characters that don't have _some_
> special meaning however. '/' would fill the bill, but I understand what
> you mean about that having connotations of a pathname.

Yeah, the problem with '/' is that crush_location of the form
"host:foo/rack:bar/row:baz" is not a path to the root of the tree,
but rather just a set of nodes: foo, bar and baz can belong to
completely different subtrees and would be matched independent of
each other.  The only reason that is not ambiguous is that CRUSH
enforces globally unique bucket names.

Having to escape is unfortunate, but I thought it was a (slightly)
lesser evil.  If folks think that '/' isn't that confusing or have
other ideas, now is the time to speak up!

Thanks,

                Ilya