Brandon Lamb wrote:
Replies are inline, hopefully im right here.... ;-)
<spec example snipped>
Note: it is assumed that host-a:/data/a, host-b:/data/b,
host-ns:/data/ns exist.
Q. Does gluster have a problem with server spec volumes which do
not exist on a given host?
I believe you are asking "what happens when you export a non-existant
directory as a volume?". There should be an error in the logs correct?
From the "Aggregating Three Storage
Servers with Unify" example is does not seem like it would, since
the namespace volume is _not_ on all nodes.
Right, when creating your client volume spec you define which server
to get the ns volume from. See below. Line 4 defines the remote host
to get the remote ns sub volume. Line 5 specifies the name of the ns
subvoluem from the server spec file. However if all of your servers
are using the same server volume spec file that you included in your
original post, then to be correct they *should* all have a ns
directory in order to not give an error. But on your clients, it is
only going to use the ns directory on the server that you specify in
the volume definition (line 1).
1 volume remote-ns
2 type protocol/client
3 option transport-type tcp/client
4 option remote-host host-ns
5 option remote-subvolume ns
6 end-volume
Right. So, in cases in which a namespace volume is specified, I gather
that I should expect there to be an error logged on all server hosts except
the one exporting the namespace. And, that such errors are _not_ fatal.
To expand, the example server volume specs seem to be minimalistic by
specifying:
-----
volume brick
type storage/posix
option directory /data/export
end-volume
-----
This assumes uniformity of the "exported" filesyetem (i.e., /data/export)
and allows a common "volume brick" for the stanza.
My question comes from wanting to export multiple, differently named,
directories from different hosts (assume 1 dir/host). Must I create a
separate server volume spec for each host, or can I simply put all the
information into one spec file and ignore the errors?
Thanks,
John
