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 [email protected] http://lists.gluster.org/mailman/listinfo/gluster-users
