On Mon, May 1, 2017 at 11:43 PM, Shyam <[email protected]> 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 [email protected] http://lists.gluster.org/mailman/listinfo/gluster-users
