Bug 788563 - converting a distribute to distributed-stripe-replicate makes some of the files invisible
Summary: converting a distribute to distributed-stripe-replicate makes some of the fil...
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: GlusterFS
Classification: Community
Component: core
Version: mainline
Hardware: x86_64
OS: Linux
high
high
Target Milestone: ---
Assignee: Amar Tumballi
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-02-08 13:39 UTC by shylesh
Modified: 2013-12-19 00:07 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-03-30 03:02:55 UTC
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:


Attachments (Terms of Use)

Description shylesh 2012-02-08 13:39:00 UTC
Description of problem:
Converted a volume dist--->dist-stripe----->dist-stripe-replicate and some of the files are not visible through ls command

Version-Release number of selected component (if applicable):
Mainline

How reproducible:
always

Steps to Reproduce:
1. create a distribute volume with 2 bricks
2. through add-brick change the volume to dist-stripe 
3. again through add-brick change the volume type to dist-stripe-replicate and create some files.
  
Actual results:
some of the files are not visible

Expected results:


Additional info:
ran ls on the mount point , op_ret is set to -1 in dht_readdirp_cbk.

#0  dht_readdirp_cbk (frame=0x7f52c8a7e62c, cookie=0x7f52c8a80060,
    this=0xcb7d30, op_ret=-1, op_errno=2, orig_entries=0x7f52b4004bd0)
    at dht-common.c:2647
#1  0x00007f52c43f7620 in stripe_readdirp_entry_stat_cbk (
    frame=0x7f52c8a80060, cookie=0xd18b30, this=0xcb6470, op_ret=0,
    op_errno=0, buf=0x7fffe798f210) at stripe.c:4161
#2  0x00007f52c463432b in afr_stat_cbk (frame=0x7f52c8a803bc, cookie=0x0,
    this=0xcb3f50, op_ret=0, op_errno=0, buf=0x7fffe798f210)
    at afr-inode-read.c:215
#3  0x00007f52c48fd9ac in client3_1_stat_cbk (req=0x7f52af724c0c,
    iov=0x7f52af724c4c, count=1, myframe=0x7f52c8a80264)
    at client3_1-fops.c:420
#4  0x00007f52c9c4518f in rpc_clnt_handle_reply (clnt=0xcdb1f0,
    pollin=0xcf4290) at rpc-clnt.c:790
#5  0x00007f52c9c4574e in rpc_clnt_notify (trans=0xcdb520, mydata=0xcdb220,
    event=RPC_TRANSPORT_MSG_RECEIVED, data=0xcf4290) at rpc-clnt.c:909
#6  0x00007f52c9c3f482 in rpc_transport_notify (this=0xcdb520,
    event=RPC_TRANSPORT_MSG_RECEIVED, data=0xcf4290) at rpc-transport.c:498
#7  0x00007f52c576a028 in socket_event_poll_in (this=0xcdb520) at socket.c:1675
#8  0x00007f52c576aa7e in socket_event_handler (fd=22, idx=11, data=0xcdb520,
    poll_in=1, poll_out=0, poll_err=0) at socket.c:1790

Comment 1 Amar Tumballi 2012-02-09 02:03:22 UTC
have to come out with a valid metric for possible volume changes. Till then keep this open. I suspect this would be one of the 'not supported' volume change option.

Comment 2 Amar Tumballi 2012-03-30 03:02:55 UTC
marking as known issue. Currently added a CLI warning (http://review.gluster.com/3034) for this configuration. Not going to fix the behavior.


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