From f191bb7bc1abd250bdf0a5a6972ce95fcbd3314b Mon Sep 17 00:00:00 2001 From: Raghavendra Bhat Date: Fri, 8 Jun 2018 09:54:00 -0400 Subject: features/snapview-server: validate the fs instance before doing fop there PROBLEM: ======== USS design depends on snapview-server translator communicating with each individual snapshot via gfapi. So, the snapview-server xlator maintains the glfs instance (thus the snapshot) to which a inode belongs to by storing it inside the inode context. Suppose, a file from a snapshot is opened by a application, and the fd is still valid from application's point of view (i.e. application has not yet closed fd). Now, if the snapshot to which the opened file belongs to is deleted, then the glfs_t instance corresponding to the snapshot is destroyed by snapview-server as part of snap deletion. But now, if the application does IO on the fd it has kept open, then snapview server tries to send that request to the corresponding snap via glfs instance for that snapshot stored in the inode context for the file on which the application is sending the fop. And this results in freed up glfs_t pointer being accessed and causes a segfault. FIX: === For fd based operations, check whether the glfs instance that the inode contains in its context, is still valid or not. For non fd based operations, usually lookup should guarantee that. But if the file was already looked up, and the client accessing the snap data (either NFS, or native glusterfs fuse) does not bother to send a lookup and directly sends a path based fop, then that path based fop should ensure that the fs instance is valid. Change-Id: I881be15ec46ecb51aa844d7fd41d5630f0d644fb updates: bz#1602070 Signed-off-by: Raghavendra Bhat --- tests/basic/open-fd-snap-delete.t | 74 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 74 insertions(+) create mode 100644 tests/basic/open-fd-snap-delete.t (limited to 'tests') diff --git a/tests/basic/open-fd-snap-delete.t b/tests/basic/open-fd-snap-delete.t new file mode 100644 index 00000000000..a9f47cac19d --- /dev/null +++ b/tests/basic/open-fd-snap-delete.t @@ -0,0 +1,74 @@ +#!/bin/bash + +. $(dirname $0)/../include.rc +. $(dirname $0)/../volume.rc +. $(dirname $0)/../snapshot.rc +. $(dirname $0)/../fileio.rc + +cleanup; + +TEST init_n_bricks 3; +TEST setup_lvm 3; + +# start glusterd +TEST glusterd; + +TEST pidof glusterd; + +TEST $CLI volume create $V0 $H0:$L1 $H0:$L2 $H0:$L3; +TEST $CLI volume set $V0 nfs.disable false + + +TEST $CLI volume start $V0; + +TEST $GFS --volfile-server=$H0 --volfile-id=$V0 $M0; + +for i in {1..10} ; do echo "file" > $M0/file$i ; done + +# Create file and directory +TEST touch $M0/f1 +TEST mkdir $M0/dir + +TEST $CLI snapshot config activate-on-create enable +TEST $CLI volume set $V0 features.uss enable; + +for i in {1..10} ; do echo "file" > $M0/dir/file$i ; done + +TEST $CLI snapshot create snap1 $V0 no-timestamp; + +for i in {11..20} ; do echo "file" > $M0/file$i ; done +for i in {11..20} ; do echo "file" > $M0/dir/file$i ; done + +TEST $CLI snapshot create snap2 $V0 no-timestamp; + +TEST fd1=`fd_available` +TEST fd_open $fd1 'r' $M0/.snaps/snap2/dir/file11; +TEST fd_cat $fd1 + +TEST $CLI snapshot delete snap2; + +TEST ! fd_cat $fd1; + +# the return value of this command (i.e. fd_close) depetends +# mainly on how the release operation on a file descriptor is +# handled in snapview-server process. As of now snapview-server +# returns 0 for the release operation. And it is similar to how +# posix xlator does. So, as of now the expectation is to receive +# success for the close operation. +TEST fd_close $fd1; + +# This check is mainly to ensure that the snapshot daemon +# (snapd) is up and running. If it is not running, the following +# stat would receive ENOTCONN. + +TEST stat $M0/.snaps/snap1/dir/file1 + +TEST $CLI snapshot delete snap1; + +TEST rm -rf $M0/*; + +TEST $CLI volume stop $V0; + +TEST $CLI volume delete $V0; + +cleanup -- cgit