[Gluster-users] gluster volume create

[Andreas Hollaus]

Hi and thanks,

Well, I definitely don't want to ruin my change log (the extended attributes), so
I'll have to think of a new way to integrate glusterfs in our use case.
Thanks for confirming my suspicion.


Regards
Andreas

On 04/13/15 06:16, Atin Mukherjee wrote:
>
> On 04/11/2015 02:25 PM, Andreas Hollaus wrote:
>> Hi and thanks,
>>
>> Well, I guess I didn't explain my problem particularly well. Sorry for
>> that.
>>
>> I guess that a normal gluster user would in the beginning add the
>> replica bricks required and then, whenever the servers restarts, let
>> gluster restart using the same configuration files as before the
>> restart. Restarts would happen again and again, without any manual
>> interaction changing the storage configuration. Every time you add a
>> brick, you would need to sync the new brick for it to be a replica of
>> the other bricks and that would take some time.
>>
>> My case is worse. When setting up this replicated file system, I would
>> do the same. However, at an early stage of every server restart I would
>> need to make the local brick available to my clients on all servers.
>> That means before the servers get in contact with each other.
>>
>> At this stage, I would like to have a volume which is not replicated on
>> every server. After a while, these single brick volumes would be dropped
>> and replaced by the replicated volume I used before the restart.
>>
>> All these stages (and volumes) I describe would make use of the same
>> physical storage place (bricks). As long as no writing is involved with
>> the single brick volumes, I wouldn't risk ending up in a split brain
>> situation when I restore the replicated volume.
>>
>> Restoring the volume would be done by keeping a backup of the
>> configuration files which define the replicated volume. Restarting the
>> gluster daemons using these configuration files would restore the
>> replicated volume without having to add any bricks. The reason I don't
>> want to add the brick at each restart, is that it would mean some
>> penalty to sync the new brick. That new brick already contains all the
>> necessary files from the time before the server restart.
>>
>> Sorry for this complex and strange way of using glusterfs, but my task
>> is to try to find a way to use it given a set of fixed use cases that we
>> have. I know that this is not an easy thing to do, but I would at least
>> want to find some way to implement this (good or bad). I think it's
>> possible, but it may be too inefficient to be a good solution.
>>
>> So, back to my original question: Would this 'gluster volume create
>> myvol local_IP:/path/to/brick' affect the data or meta-data on the brick
>> in any way? I think that is the most critical command in the chain, as I
>> don't expect starting or mounting the volume to affect anything. I want
>> to avoid affecting the (meta-)data as I intend to restore the replicated
>> volume I used before the restart without gluster noticing that the brick
>> was actually used in another configuration in between.
> Answer to your question is "partially yes", though it doesn't affect the
> data residing in the brick but it resets all of its meta data and set
> new extended attributes.
>>
>> Regards
>> Andreas
>>
>>
>> On 04/11/2015 09:18 AM, Atin Mukherjee wrote:
>>> On 04/11/2015 01:21 AM, Andreas Hollaus wrote:
>>>> Hi,
>>>>
>>>> I wonder what happens when the command 'gluster volume create...' is
>>>> executed? How is the file system on the brick affected by that command,
>>>> data and meta-data (extended attributes)?
>>>>
>>>> The reason for this question is that I have a strange use case where my
>>>> 2 (mirrored) servers are restarted. At an early stage of the reboot
>>>> phase, I have to create a new gluster file system on each server so that
>>>> the same directory can be used for read access. Later on, I would like
>>>> to delete these single server volumes and replace them with the mirrored
>>>> gluster volume I used before the restart.
>>>>
>>>> I guess I can restore the previous volume definition from a backup of
>>>> the gluster configuration files, but I'm worried that the 'gluster
>>>> volume create...' command might have affected the brick so that it is in
>>>> a different state compared to before the restart, when the restored
>>>> gluster configuration was valid. I realize that for this to work, the
>>>> extended attributes can not change while the mirrored volume is stopped.
>>>>
>>>> Any idea if I can use glusterfs like this or am I violating some rules?
>>> If I've understood your requirement correctly you are trying to convert
>>> a distributed volume into a replicate one. In that case you would need
>>> to convert it through add brick mentioned the replica count. I don't
>>> think you would face any issues for restoring configurations if all the
>>> steps are performed correctly.
>>>
>>> ~Atin
>>>> Regards
>>>> Andreas
>>>> _______________________________________________
>>>> Gluster-users mailing list
>>>> Gluster-users at gluster.org
>>>> http://www.gluster.org/mailman/listinfo/gluster-users
>>>>
>>