Bug 1468202 - inodelk in dht_migrate_file is ineffective for hardlink migration
Summary: inodelk in dht_migrate_file is ineffective for hardlink migration
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: GlusterFS
Classification: Community
Component: distribute
Version: mainline
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: ---
Assignee: Susant Kumar Palai
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-07-06 10:00 UTC by Susant Kumar Palai
Modified: 2020-02-18 08:13 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-02-18 08:13:19 UTC
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Embargoed:

Attachments (Terms of Use)

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.
Note You need to log in before you can comment on or make changes to this bug.