Bug 884594

Summary: handle mtime updates properly in dht
Product: [Community] GlusterFS Reporter: Amar Tumballi <amarts>
Component: distributeAssignee: Nagaprasad Sathyanarayana <nsathyan>
Status: CLOSED EOL QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: mainlineCC: bugs, chrisw, gluster-bugs, rwheeler, smohan
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-10-22 15:46:38 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 Amar Tumballi 2012-12-06 11:10:53 UTC
On 11/18/2012 11:11 PM, Amar Tumballi wrote:
> On 11/15/2012 11:18 PM, Anand Avati wrote:
>> Re: http://review.gluster.org/3737. How are we handling utimes() call on
>> the directory. I think we will end up returning the old (higher) mtime
>> and atime even after setting them backwards, right? We need to figure
>> out a way around that.
>>
>
> True, as for as I remember, it doesn't handle it. Let me know what you
> think about below approach:
>
> two cases:
>
> 1. the 'setattr()' call passes through the dht xlator:
>     -> clear inode_ctx in the call itself, so in callback we will have
> it set properly.
>
> 2. in case of other clients (is where the complexity is):
>     -> in set_if_greater_time(), need to have another variable which is
> per call maximum (ie, check for maximum time in that particular call).
> Only if this is more than or equal to inode-ctx value, then everything
> fine, otherwise, set inode-ctx to per-call-maximum variable.

Yes, this is what I was thinking roughly. We need to delay updating inode-ctx to as late as possible. In cases where we have aggregated the iatt from all subvolumes, we "set" the new time into ctx. In cases where we get iatt from only one subvol, then use the current "set max" logic.

Comment 3 Kaleb KEITHLEY 2015-10-22 15:46:38 UTC
because of the large number of bugs filed against mainline version\ is ambiguous and about to be removed as a choice.

If you believe this is still a bug, please change the status back to NEW and choose the appropriate, applicable version for it.