[Gluster-users] gluster volume create failure
lbalbalba at gmail.com
Tue May 14 20:31:17 UTC 2013
I think im sticking to using '/export/lvmvolumename/' as the
mountpoint, and a subdir 'brick' in that for glusterfs:
This has the same advantage as you mention, and tells me what lvm2
volumes are part of the gluster volume. I think im not going to use
numbers like 'brick1' 'brick2' in the directory structure: 'gluster
volume info' also talks about brick numbers in its output, whicj can
be confusing and lead to stuff like this :
gluster volume info
Volume Name: glustervol01
Volume ID: 96e28207-aaa0-4a33-9973-7021790f1f93
Number of Bricks: 1 x 2 = 2
On Tue, May 14, 2013 at 10:05 PM, Brian Candler <B.Candler at pobox.com> wrote:
> On Tue, May 14, 2013 at 08:56:02PM +0200, John Smith wrote:
>> Thanks. Is there a preferred naming convention to go along with it ?
> It's up to you, but I used /exports/brick1/myvol, /exports/brick2/myvol
> and it seemed logical to me.
> There's an important benefit to doing this. If the filesystem doesn't mount
> for any reason at startup, then you are left with an empty /exports/brick1
> mount point. glusterd sees that /exports/brick1/myvol is not present and so
> glusterd terminates. This is what you want.
> If you had used /exports/brick1 as the brick then glusterd would start up,
> see the empty directory, and if it's part of a replicated volume would start
> self-healing data into it - potentially filling up your root filesystem very
> Another side benefit is that you can if you wish re-use the same filesystem
> as a member of multiple volumes. For example
> might be part of a replicated volume, and
> might be part of a distributed volume.
> This can be simpler and easier to manage than using something like LVM to
> slice up your brick, although the volume "free space" you see may not work
> quite how you expect.
More information about the Gluster-users