Gluster users - May 2017 - Add single server

On Mon, May 1, 2017 at 11:43 PM, Shyam <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?

>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.gluster.org/pipermail/gluster-users/attachments/20170501/aa79593e/attachment.html>

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

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