[Gluster-users] Add single server

[Shyam]

On 05/01/2017 02:42 PM, Pranith Kumar Karampuri wrote:
>
>
> On Tue, May 2, 2017 at 12:07 AM, Shyam <srangana at redhat.com
> <mailto:srangana at redhat.com>> wrote:
>
>     On 05/01/2017 02:23 PM, Pranith Kumar Karampuri wrote:
>
>
>
>         On Mon, May 1, 2017 at 11:43 PM, Shyam <srangana at redhat.com
>         <mailto:srangana at redhat.com>
>         <mailto:srangana at redhat.com <mailto:srangana at redhat.com>>> 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.

Yes, I think this is the direction to solve the 2 bricks on a single FS 
as well. Also, IMO, the weight of accounting at each directory level 
that quota brings in seems/is heavyweight to solve just *this* problem.

>
>
>
>
>
>
>
>             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