Bug 884594 - handle mtime updates properly in dht
Summary: handle mtime updates properly in dht
Keywords:
Status: CLOSED EOL
Alias: None
Product: GlusterFS
Classification: Community
Component: distribute
Version: mainline
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
Assignee: Nagaprasad Sathyanarayana
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-12-06 11:10 UTC by Amar Tumballi
Modified: 2016-02-18 00:21 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-10-22 15:46:38 UTC
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Embargoed:


Attachments (Terms of Use)

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.


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