Bug 1548270 - DHT calls dht_lookup_everywhere for 1xn volumes
Summary: DHT calls dht_lookup_everywhere for 1xn volumes
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: GlusterFS
Classification: Community
Component: distribute
Version: 3.12
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: bugs@gluster.org
QA Contact:
URL:
Whiteboard:
Depends On: 1546620 1548271
Blocks: 1545570
TreeView+ depends on / blocked
 
Reported: 2018-02-23 03:35 UTC by Nithya Balachandran
Modified: 2018-04-06 11:06 UTC (History)
5 users (show)

Fixed In Version: glusterfs-3.12.7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1546620
Environment:
Last Closed: 2018-04-06 11:06:55 UTC
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:


Attachments (Terms of Use)

Description Nithya Balachandran 2018-02-23 03:35:13 UTC
+++ This bug was initially created as a clone of Bug #1546620 +++

+++ This bug was initially created as a clone of Bug #1545570 +++

Description of problem:

DHT lookup does not handle lookups on 1xn volumes optimally. It calls a dht_lookup_everywhere even though it has already checked the only subvol leading to repeated, redundant lookups for entries.

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


How reproducible:
Consistently

Steps to Reproduce:
1. Create a 1x3 volume and set client-log-level to DEBUG
2. Fuse mount the volume and create some files (touch file-{1..10})
3. Check the mnt log for dht messages

Actual results:
[2018-02-15 09:53:04.799711] D [MSGID: 0] [dht-common.c:2761:dht_lookup] 0-gitmo-dht: Calling fresh lookup for /file-10 on gitmo-replicate-0
[2018-02-15 09:53:04.800179] D [MSGID: 0] [dht-common.c:2344:dht_lookup_cbk] 0-gitmo-dht: fresh_lookup returned for /file-10 with op_ret -1 [No such file or directory]
[2018-02-15 09:53:04.800188] D [MSGID: 0] [dht-common.c:2357:dht_lookup_cbk] 0-gitmo-dht: Entry /file-10 missing on subvol gitmo-replicate-0
[2018-02-15 09:53:04.800196] D [MSGID: 0] [dht-common.c:2128:dht_lookup_everywhere] 0-gitmo-dht: winding lookup call to 1 subvols
[2018-02-15 09:53:04.800670] D [MSGID: 0] [dht-common.c:1930:dht_lookup_everywhere_cbk] 0-gitmo-dht: returned with op_ret -1 and op_errno 2 (/file-10) from subvol gitmo-replicate-0
[2018-02-15 09:53:04.800679] D [MSGID: 0] [dht-common.c:1594:dht_lookup_everywhere_done] 0-gitmo-dht: STATUS: hashed_subvol gitmo-replicate-0 cached_subvol null
[2018-02-15 09:53:04.800684] D [MSGID: 0] [dht-common.c:1655:dht_lookup_everywhere_done] 0-gitmo-dht: There was no cached file and  unlink on hashed is not skipped /file-10
[2018-02-15 09:53:04.800691] D [MSGID: 0] [dht-common.c:1658:dht_lookup_everywhere_done] 0-stack-trace: stack-address: 0x7f03e4000d50, gitmo-dht returned -1 error: No such file or directory [No such file or directory]


Expected results:

DHT need not call dht_lookup_everywhere for 1xn volumes

Additional info:

--- Additional comment from Red Hat Bugzilla Rules Engine on 2018-02-15 04:58:27 EST ---

This bug is automatically being proposed for the release of Red Hat Gluster Storage 3 under active development and open for bug fixes, by setting the release flag 'rhgs‑3.4.0' to '?'. 

If this bug should be proposed for a different release, please manually change the proposed release flag.

--- Additional comment from Red Hat Bugzilla Rules Engine on 2018-02-15 07:26:53 EST ---

This bug is automatically being provided 'pm_ack+' for the release flag 'rhgs‑3.4.0', having been appropriately marked for the release, and having been provided ACK from Development and QE

--- Additional comment from Red Hat Bugzilla Rules Engine on 2018-02-16 07:26:30 EST ---

Since this bug has has been approved for the RHGS 3.4.0 release of Red Hat Gluster Storage 3, through release flag 'rhgs-3.4.0+', and through the Internal Whiteboard entry of '3.4.0', the Target Release is being automatically set to 'RHGS 3.4.0'

--- Additional comment from Worker Ant on 2018-02-18 23:24:37 EST ---

REVIEW: https://review.gluster.org/19581 (cluster/dht: Handle single dht child in dht_lookup) posted (#1) for review on master by N Balachandran

--- Additional comment from Worker Ant on 2018-02-22 05:51:59 EST ---

COMMIT: https://review.gluster.org/19581 committed in master by "Raghavendra G" <rgowdapp@redhat.com> with a commit message- cluster/dht: Handle single dht child in dht_lookup

This patch limits itself to only handling the case
where no file (data or linkto) exists on the subvol.

Additional cases to be handled:
1. A linkto file was found on the only child subvol. This currently
calls dht_lookup_everywhere which eventually deletes it. It can be
deleted directly as it will not be pointing to a valid subvol.
2. Directory lookups - locking might be unnecessary in some cases.

Change-Id: I940ba34531f2aaee1d36fd9ca45ecfd46be662a4
BUG: 1546620
Signed-off-by: N Balachandran <nbalacha@redhat.com>

Comment 1 Worker Ant 2018-02-23 04:27:43 UTC
REVIEW: https://review.gluster.org/19619 (cluster/dht: Handle single dht child in dht_lookup) posted (#1) for review on release-3.12 by N Balachandran

Comment 2 Worker Ant 2018-03-05 06:47:41 UTC
COMMIT: https://review.gluster.org/19619 committed in release-3.12 by "N Balachandran" <nbalacha@redhat.com> with a commit message- cluster/dht: Handle single dht child in dht_lookup

This patch limits itself to only handling the case
where no file (data or linkto) exists on the subvol.

Additional cases to be handled:
1. A linkto file was found on the only child subvol. This currently
calls dht_lookup_everywhere which eventually deletes it. It can be
deleted directly as it will not be pointing to a valid subvol.
2. Directory lookups - locking might be unnecessary in some cases.

> Change-Id: I940ba34531f2aaee1d36fd9ca45ecfd46be662a4
> BUG: 1546620
> Signed-off-by: N Balachandran <nbalacha@redhat.com>

Change-Id: I940ba34531f2aaee1d36fd9ca45ecfd46be662a4
BUG: 1548270
Signed-off-by: N Balachandran <nbalacha@redhat.com>

Comment 3 Jiffin 2018-04-06 11:06:55 UTC
This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.12.7, please open a new bug report.

glusterfs-3.12.7 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution.

[1] http://lists.gluster.org/pipermail/maintainers/2018-March/004303.html
[2] https://www.gluster.org/pipermail/gluster-users/


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