From dcc1696045f12127ff37e6312a04c0024c8a4e24 Mon Sep 17 00:00:00 2001 From: Raghavendra Bhat Date: Tue, 15 Jul 2014 15:55:34 +0530 Subject: mgmt/glusterd: do not check for snapd handle in restore if uss is disabled Change-Id: I01afe64685a5794cce9265580c6c5de57a045201 BUG: 1119582 Signed-off-by: Raghavendra Bhat Reviewed-on: http://review.gluster.org/8310 Tested-by: Gluster Build System Reviewed-by: Kaushal M --- xlators/mgmt/glusterd/src/glusterd-store.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) (limited to 'xlators/mgmt/glusterd') diff --git a/xlators/mgmt/glusterd/src/glusterd-store.c b/xlators/mgmt/glusterd/src/glusterd-store.c index 06e8101a3a5..3f241bbe53a 100644 --- a/xlators/mgmt/glusterd/src/glusterd-store.c +++ b/xlators/mgmt/glusterd/src/glusterd-store.c @@ -2126,6 +2126,25 @@ glusterd_store_retrieve_snapd (glusterd_volinfo_t *volinfo) goto out; } + /* + * This is needed for upgrade situations. Say a volume is created with + * older version of glusterfs and upgraded to a glusterfs version equal + * to or greater than GD_OP_VERSION_3_6_0. The older glusterd would not + * have created the snapd.info file related to snapshot daemon for user + * serviceable snapshots. So as part of upgrade when the new glusterd + * starts, as part of restore (restoring the volume to be precise), it + * tries to snapd related info from snapd.info file. But since there was + * no such file till now, the restore operation fails. Thus, to prevent + * it from happening check whether user serviceable snapshots features + * is enabled before restoring snapd. If its disbaled, then simply + * exit by returning success (without even checking for the snapd.info). + */ + + if (!dict_get_str_boolean (volinfo->dict, "features.uss", _gf_false)) { + ret = 0; + goto out; + } + GLUSTERD_GET_VOLUME_DIR(volpath, volinfo, conf); snprintf (path, sizeof (path), "%s/%s", volpath, -- cgit