andy/glusterfs
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

protocol/client: Do not fallback to anon-fd if fd is not open

Browse Source 
If an open comes on a file when a brick is down and after the brick comes up,
a fop comes on the fd, client xlator would still wind the fop on anon-fd
leading to wrong behavior of the fops in some cases.

Example:
If lk fop is issued on the fd just after the brick is up in the scenario above,
lk fop will be sent on anon-fd instead of failing it on that client xlator.
This lock will never be freed upon close of the fd as flush on anon-fd is
invalid and is not wound below server xlator.

As a fix, failing the fop unless the fd has FALLBACK_TO_ANON_FD flag.

Change-Id: I77692d056660b2858e323bdabdfe0a381807cccc
fixes bz#1699198
Signed-off-by: Pranith Kumar K <pkarampu@redhat.com>
(cherry picked from commit 92ae26ae8039847e38c738ef98835a14be9d4296)
This commit is contained in:
Pranith Kumar K 2019-03-28 17:55:54 +05:30 committed by Shyamsundar Ranganathan
parent 74db82dd5d
commit fbba6e397f
2 changed files with 43 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

36
tests/bugs/protocol/bug-1390914.t Normal file
View File

@ -0,0 +1,36 @@
#!/bin/bash
. $(dirname $0)/../../include.rc
. $(dirname $0)/../../volume.rc
. $(dirname $0)/../../fileio.rc
cleanup;
#test that fops are not wound on anon-fd when fd is not open on that brick
TEST glusterd;
TEST pidof glusterd
TEST $CLI volume create $V0 replica 3 $H0:$B0/${V0}{1,2,3};
TEST $CLI volume set $V0 performance.open-behind off
TEST $CLI volume set $V0 diagnostics.client-log-level DEBUG
TEST $CLI volume heal $V0 disable
TEST $CLI volume start $V0
TEST $CLI volume profile $V0 start
TEST $GFS -s $H0 --volfile-id=$V0 --direct-io-mode=enable $M0;
TEST touch $M0/1
TEST kill_brick $V0 $H0 $B0/${V0}1
TEST fd_open 200 'w' "$M0/1"
TEST $CLI volume start $V0 force
EXPECT_WITHIN $PROCESS_UP_TIMEOUT "1" afr_child_up_status $V0 0
#lk should only happen on 2 bricks, if there is a bug, it will plant a lock
#with anon-fd on first-brick which will never be released because flush won't
#be wound below server xlator for anon-fd
TEST flock -x -n 200
TEST fd_close 200
TEST fd_open 200 'w' "$M0/1"
#this lock will fail if there is a stale lock
TEST flock -x -n 200
TEST fd_close 200
cleanup;

8
xlators/protocol/client/src/client-helpers.c
View File

@ -419,7 +419,13 @@ client_get_remote_fd(xlator_t *this, fd_t *fd, int flags, int64_t *remote_fd)
{
fdctx = this_fd_get_ctx(fd, this);
if (!fdctx) {
*remote_fd = GF_ANON_FD_NO;
if (fd->anonymous) {
*remote_fd = GF_ANON_FD_NO;
} else {
*remote_fd = -1;
gf_msg_debug(this->name, EBADF, "not a valid fd for gfid: %s",
uuid_utoa(fd->inode->gfid));
}
} else {
if (__is_fd_reopen_in_progress(fdctx))
*remote_fd = -1;