Bug 884594 - handle mtime updates properly in dht
handle mtime updates properly in dht
Product: GlusterFS
Classification: Community
Component: distribute (Show other bugs)
Unspecified Unspecified
medium Severity medium
: ---
: ---
Assigned To: Nagaprasad Sathyanarayana
Depends On:
  Show dependency treegraph
Reported: 2012-12-06 06:10 EST by Amar Tumballi
Modified: 2016-02-17 19:21 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-10-22 11:46:38 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Amar Tumballi 2012-12-06 06:10:53 EST
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 11:46:38 EDT
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.