Bug 1007921 - Remove-brick: Directories created after "remove-brick start" should not go to decommissioned bricks
Summary: Remove-brick: Directories created after "remove-brick start" should not go to...
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: Red Hat Gluster Storage
Classification: Red Hat
Component: glusterfs
Version: 2.1
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
: ---
Assignee: Bug Updates Notification Mailing List
QA Contact: storage-qa-internal@redhat.com
URL:
Whiteboard:
Depends On:
Blocks: 1286184
TreeView+ depends on / blocked
 
Reported: 2013-09-13 14:53 UTC by shylesh
Modified: 2015-11-27 12:21 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1286184 (view as bug list)
Environment:
Last Closed: 2015-11-27 12:16:55 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description shylesh 2013-09-13 14:53:03 UTC
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.