[Gluster-devel] glusterfs-3.3.0qa34 released

[Amar Tumballi]

On 04/18/2012 12:26 PM, Ian Latter wrote:
> Hello,
>
>
>    I've written a work around for this issue (in 3.3.0qa35)
> by adding a new configuration option to glusterd
> (ignore-strict-checks) but there are additional checks
> within the posix brick/xlator.  I can see that volume starts
> but the bricks inside it fail shortly there-after, and that of
> the 5 disks in my volume three of them have one
> volume_id and two them have another - so this isn't going
> to be resolved without some human intervention.
>
>    However, while going through the posix brick/xlator I
> found the "volume-id" parameter.  I've tracked it back
> to the volinfo structure in the glusterd xlator.
>
>    So before I try to code up a posix inheritance for my
> glusterd work around (ignoring additional checks so
> that a new volume_id is created on-the-fly / as-needed),
> does anyone know of a CLI method for passing the
> volume-id into glusterd (either via "volume create" or
> "volume set")?  I don't see one from the code ...
> glusterd_handle_create_volume does a uuid_generate
> and its not a feature of glusterd_volopt_map ...
>
>    Is a user defined UUID init method planned for the CLI
> before 3.3.0 is released?  Is there a reason that this
> shouldn't be permitted from the CLI "volume create" ?
>
>
We don't want to bring in this option to CLI. That is because we don't 
think it is right to confuse USER with more options/values. 'volume-id' 
is a internal thing for the user, and we don't want him to know about in 
normal use cases.

In case of 'power-users' like you, If you know what you are doing, the 
better solution is to do 'setxattr -x trusted.volume-id $brick' before 
starting the brick, so posix translator anyway doesn't get bothered.

Regards,
Amar