Bug 1468202

Summary:	inodelk in dht_migrate_file is ineffective for hardlink migration
Product:	[Community] GlusterFS	Reporter:	Susant Kumar Palai <spalai>
Component:	distribute	Assignee:	Susant Kumar Palai <spalai>
Status:	CLOSED DEFERRED	QA Contact:
Severity:	medium	Docs Contact:
Priority:	high
Version:	mainline	CC:	bugs
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-02-18 08:13:19 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Susant Kumar Palai 2017-07-06 10:00:02 UTC

Description of problem:
dht_migrate_file takes inodelk before migrating a file to avoid clash with rename operation. But the lk_owner is not filled here(lk_owner is basically zero) making it ineffective for hardlink migration since hardlinks for a file need to be migrated synchronously.

This bug is created to track the fix for this.

Comment 1 Nithya Balachandran 2018-01-08 15:35:36 UTC

The inodelk APIs get the lk_owner from the frame->root->lk_owner (not the flock->l_owner) which is set to the process pid if not explicitly set by the caller. dht_migrate_file uses syncop_inodelk which does not provide access to the frame, so the lk_owner is always 0xfdfffff (-3 which is GF_CLIENT_PID_DEFRAG). As the owner is the same, the inodelk is always granted for all hardlinks.

Comment 2 Yaniv Kaul 2019-07-01 06:05:50 UTC

Status?

Comment 3 Susant Kumar Palai 2019-07-03 06:01:37 UTC

(In reply to Yaniv Kaul from comment #2)
> Status?

This is more of an optimization. We have synclock in place for now to handle hardlink migration. Will take this up in future.

Comment 4 Susant Kumar Palai 2020-02-18 08:13:19 UTC

Closing this bug as there is no functionality impact. Deferring to future release.