[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gluster-bugs
Subject:    [Bugs] [Bug 1633242] 'df' shows half as much space on volume after upgrade to RHGS 3.4
From:       bugzilla () redhat ! com
Date:       2018-09-27 15:35:32
Message-ID: bug-1633242-371520-o4dR8Srvv6 () bugzilla ! redhat ! com
[Download RAW message or body]

https://bugzilla.redhat.com/show_bug.cgi?id=1633242

Worker Ant <bugzilla-bot@gluster.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|POST                        |MODIFIED



--- Comment #3 from Worker Ant <bugzilla-bot@gluster.org> ---
COMMIT: https://review.gluster.org/21285 committed in release-5 by "Sanju
Rakonde" <srakonde@redhat.com> with a commit message- glusterd: make sure that
brickinfo->uuid is not null

Problem: After an upgrade from the version where shared-brick-count
option is not present to a version which introduced this option
causes issue at the mount point i.e, size of the volume at mount
point will be reduced by shared-brick-count value times.

Cause: shared-brick-count is equal to the number of bricks that
are sharing the file system. gd_set_shared_brick_count() calculates
the shared-brick-count value based on uuid of the node and fsid of
the brick. https://review.gluster.org/#/c/glusterfs/+/19484 handles
setting of fsid properly during an upgrade path. This patch assumed
that when the code path is reached, brickinfo->uuid is non-null.
But brickinfo->uuid is null for all the bricks, as the uuid is null
https://review.gluster.org/#/c/glusterfs/+/19484 couldn't reached the
code path to set the fsid for bricks. So, we had fsid as 0 for all
bricks, which resulted in gd_set_shared_brick_count() to calculate
shared-brick-count in a wrong way. i.e, the logic written in
gd_set_shared_brick_count() didn't work as expected since fsid is 0.

Solution: Before control reaches the code path written by
https://review.gluster.org/#/c/glusterfs/+/19484,
adding a check for whether brickinfo->uuid is null and
if brickinfo->uuid is having null value, calling
glusterd_resolve_brick will set the brickinfo->uuid to a 
proper value. When we have proper uuid, fsid for the bricks
will be set properly and shared-brick-count value will be
caluculated correctly.

Please take a look at the bug
https://bugzilla.redhat.com/show_bug.cgi?id=1632889
for complete RCA

Steps followed to test the fix:
1. Created a 2 node cluster, the cluster is running with binary
which doesn't have shared-brick-count option
2. Created a 2x(2+1) volume and started it
3. Mouted the volume, checked size of volume using df
4. Upgrade to a version where shared-brick-count is introduced
(upgraded the nodes one by one i.e, stop the glusterd, upgrade the node
and start the glusterd).
5. after upgrading both the nodes, bumped up the cluster.op-version
6. At mount point, df shows the correct size for volume.

> backport of https://review.gluster.org/#/c/glusterfs/+/21278/
> Change-Id: Ib9f078aafb15e899a01086eae113270657ea916b
> Signed-off-by: Sanju Rakonde <srakonde@redhat.com>
(cherry picked from commit f1e9b878ce2067db83a0baa5f384eda87287719d)

fixes: bz#1633242
Change-Id: Ib9f078aafb15e899a01086eae113270657ea916b
Signed-off-by: Sanju Rakonde <srakonde@redhat.com>

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
_______________________________________________
Bugs mailing list
Bugs@gluster.org
https://lists.gluster.org/mailman/listinfo/bugs
[prev in list] [next in list] [prev in thread] [next in thread]