On Tue, May 2, 2017 at 12:07 AM, Shyam <[email protected]> wrote: > On 05/01/2017 02:23 PM, Pranith Kumar Karampuri wrote: > >> >> >> On Mon, May 1, 2017 at 11:43 PM, Shyam <[email protected] >> <mailto:[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? >> > > This is true even today, if anyone uses 2 bricks from the same mount. >
That is the reason why documentation is the way it is as far as I can remember. > > I forgot a converse though, we could take a disk and partition it (LVM > thinp volumes) and use each of those partitions as bricks, avoiding the > problem of df double counting. Further thinp will help us expand available > space to other bricks on the same disk, as we destroy older bricks or > create new ones to accommodate the moving pieces (needs more careful > thought though, but for sure is a nightmare without thinp). > > I am not so much a fan of large number of thinp partitions, so as long as > that is reasonably in control, we can possibly still use it. The big > advantage though is, we nuke a thinp volume when the brick that uses that > partition, moves out of that disk, and we get the space back, rather than > having or to something akin to rm -rf on the backend to reclaim space. Other way to achieve the same is to leverage the quota functionality of counting how much size is used under a directory. > > > >> >> >> 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 >> > -- Pranith
_______________________________________________ Gluster-users mailing list [email protected] http://lists.gluster.org/mailman/listinfo/gluster-users
