Bug 1007921 - Remove-brick: Directories created after "remove-brick start" should not go to decommissioned bricks
Remove-brick: Directories created after "remove-brick start" should not go to...
Status: CLOSED DEFERRED
Product: Red Hat Gluster Storage
Classification: Red Hat
Component: glusterfs (Show other bugs)
2.1
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Bug Updates Notification Mailing List
storage-qa-internal@redhat.com
:
Depends On:
Blocks: 1286184
  Show dependency treegraph
 
Reported: 2013-09-13 10:53 EDT by shylesh
Modified: 2015-11-27 07:21 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1286184 (view as bug list)
Environment:
Last Closed: 2015-11-27 07:16:55 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description shylesh 2013-09-13 10:53:03 EDT
Description of problem:
Remove-brick: Directories created after "remove-brick start" should not go to decommissioned bricks 

Version-Release number of selected component (if applicable):
3.4.0.33rhs-1.el6rhs.x86_64

How reproducible:
Always

Steps to Reproduce:
1.created a 5x2 distributed-replicate volume
2. mounted the volume on two different mount points say /mnt1 and /mnt2 
3.ran the following scripts on the mount point

for i in {1..100}; do mkdir $i; cd $i; for j in {1..100}; do dd if=/dev/urandom of=file.$j bs=200k count=1; done; done

4.decommissioned one of the pair

5. while decommissioning is in progress create new directories inside any of the directories created above on both the mount points

6. observe in the backend directories of decommissioning bricks


Actual results:
Newly created directories are getting created on the bricks

Expected results:
New directories should not go into decommissioned bricks

Additional info:
 
Volume Name: dist-rep
Type: Distributed-Replicate
Volume ID: 6b5d55c2-5f0e-4c11-8bc9-d1face6139eb
Status: Started
Number of Bricks: 5 x 2 = 10
Transport-type: tcp
Bricks:
Brick1: 10.70.37.113:/brick1/dr0
Brick2: 10.70.37.134:/brick1/dr0
Brick3: 10.70.37.59:/brick1/dr1
Brick4: 10.70.37.133:/brick1/dr1
Brick5: 10.70.37.113:/brick1/dr2
Brick6: 10.70.37.134:/brick1/dr2
Brick7: 10.70.37.113:/brick1/dr3
Brick8: 10.70.37.134:/brick1/dr3
Brick9: 10.70.37.113:/brick1/dr4 --->decommissioned brick pair
Brick10: 10.70.37.134:/brick1/dr4--->


[root@rhs1-gold 3]# getfattr -d -m . -e hex /brick1/dr4/d2/1/2/3
getfattr: Removing leading '/' from absolute path names
# file: brick1/dr4/d2/1/2/3
trusted.gfid=0x0dd5dbc356e74c72a5088ae61ede69dc
trusted.glusterfs.dht=0x00000001000000000000000000000000

the above directory has got dht layout zeroed out but after starting remove-brick i created the below directories which were created on decommissioned bricks though didn't get the layout.

[root@rhs1-gold 3]# getfattr -d -m . -e hex /brick1/dr4/d2/1/2/3/1
getfattr: Removing leading '/' from absolute path names
# file: brick1/dr4/d2/1/2/3/1
trusted.gfid=0xe81babdeade34eb49dc8727c5b053b0a

[root@rhs1-gold 3]# getfattr -d -m . -e hex /brick1/dr4/d2/1/2/3/1/2
getfattr: Removing leading '/' from absolute path names
# file: brick1/dr4/d2/1/2/3/1/2
trusted.gfid=0x619953752cd8410680ff8000c9415be2

Note You need to log in before you can comment on or make changes to this bug.