On Mon, May 1, 2017 at 11:43 PM, Shyam <srangana@xxxxxxxxxx> wrote:
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).
Hmmm... as per my understanding, if we do this then 'df' I guess will report wrong values? available-size/free-size etc will be counted more than once?
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).
--
Pranith
_______________________________________________ Gluster-users mailing list Gluster-users@xxxxxxxxxxx http://lists.gluster.org/mailman/listinfo/gluster-users
