[Bugs] [Bug 1593538] ctime: Access time is different with in same replica/ EC volume

bugzilla at redhat.com bugzilla at redhat.com
Thu Jun 21 07:26:30 UTC 2018


https://bugzilla.redhat.com/show_bug.cgi?id=1593538

Xavi Hernandez <jahernan at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|needinfo?(amarts at redhat.com |needinfo?(amarts at redhat.com
                   |)                           |)
                   |needinfo?(jahernan at redhat.c |
                   |om)                         |



--- Comment #2 from Xavi Hernandez <jahernan at redhat.com> ---
Keeping atime synchronized in all bricks in the naive way will probably have an
important performance impact. EC and AFR would need to send all read requests
to all bricks, just to update the atime. In the case of DHT, the problem is
worse because accessing a directory (readdir) should update atime, which means
that all subvolumes should be updated. This is not scalable.

However there are applications that use atime (though I'm not sure what degree
of consistency they need), and not updating atime consistently could trigger
self-heal constantly unless we explicitly handle and parse ctime xattr in AFR
and EC.

I think we should provide this as an option (or depend on
atime/noatime/relatime mount options). It should be implemented as an special
update operation (maybe a setattr sent internally by utime xlator after
successful reads) because otherwise we would need to do big changes in DHT, AFR
and EC. In this case, read operations shouldn't update atime at all. It should
only be updated by this special internal operation. This way we make sure it's
kept consistent all the time.

We could provide options to update it continuously, lazily in the background,
using the same semantics than relatime, or not updating it at all. This way the
user can decide what's really needed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.


More information about the Bugs mailing list