On 05/01/2017 02:00 PM, Pranith Kumar Karampuri wrote:
Splitting the bricks need not be a post factum decision, we can
start with larger brick counts, on a given node/disk count, and
hence spread these bricks to newer nodes/bricks as they are added.
Let's say we have 1 disk, we format it with say XFS and that becomes a
brick at the moment. Just curious, what will be the relationship between
brick to disk in this case(If we leave out LVM for this example)?
I would assume the relation is brick to provided FS directory (not brick
to disk, we do not control that at the moment, other than providing best
practices around the same).
Today, gluster takes in a directory on host as a brick, and assuming we
retain that, we would need to split this into multiple sub-dirs and use
each sub-dir as a brick internally.
All these sub-dirs thus created are part of the same volume (due to our
current snapshot mapping requirements).
_______________________________________________
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/gluster-users
