----- Original Message ----- >From: "Amar Tumballi" <amarts@xxxxxxxxxx> >To: "Ian Latter" <ian.latter@xxxxxxxxxxxxxxxx> >Subject: Re: glusterfs-3.3.0qa34 released >Date: Wed, 18 Apr 2012 13:42:45 +0530 > > 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 > Hello Amar, I wouldn't go so far as to say that I know what I'm doing, but I'll take the compliment ;-) Thanks for the advice. I'm going to assume that I'll be revisiting this issue when we can get back into clustering (replicating distributed volumes). I.e. I'm assuming that on this path we'll end up driving out issues like split brain; https://github.com/jdarcy/glusterfs/commit/8a45a0e480f7e8c6ea1195f77ce3810d4817dc37 Cheers, -- Ian Latter Late night coder .. http://midnightcode.org/
