[Bugs] [Bug 1670718] md-cache should be loaded at a position in graph where it sees stats in write cbk

[bugzilla at redhat.com]

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

Xavi Hernandez <jahernan at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amarts at gmail.com,
                   |                            |jahernan at redhat.com,
                   |                            |moagrawa at redhat.com,
                   |                            |pkarampu at redhat.com,
                   |                            |ykaul at redhat.com
              Flags|                            |needinfo?(amarts at gmail.com)
                   |                            |needinfo?(moagrawa at redhat.c
                   |                            |om)
                   |                            |needinfo?(pkarampu at redhat.c
                   |                            |om)
                   |                            |needinfo?(ykaul at redhat.com)



--- Comment #7 from Xavi Hernandez <jahernan at redhat.com> ---
The main issue here is that write-behind is returning NULL for post iatt after
a cached write. When md-cache sees a NULL iatt, it invalidates its cache. This
happens because write-behind is not caching metadata, so it can't provide a
meaningful iatt when the write has not been processed by bricks.

On the other side, placing md-cache after write-behind requires that
write-behind serializes all operations that return an iatt (virtually all) so
that when they reach md-cache (at least those that the user has sent
sequentially and write-behind has answered directly), the previous operations
have been completely executed and updated the cached metadata. I'm not 100%
sure if this is what write-behind is doing in all cases, but doing so is
inefficient. For example, if user sends a write request and then an fstat
request, write-behind will absorb the write, but when it sees the fstat
request, the cached write needs to be flushed and the fstat delayed until the
write finishes so that the fstat gets the correct answer.

I think the good approach here would be to unify caching layers and provide an
authoritative cache with consistency guarantees. There's a github issue [1] for
this, but probably it's a very ambitious approach for a first implementation.
Maybe we could get most of the benefits by using a lock based cache that
integrates metadata and data. With this approach, an fstat after a write could
be served even without flushing the cached write, so both requests could be
served directly from client cache with no network/brick activity.

If that's the way to go, I would close this bug and create a new one (or a
feature request in github) to implement that caching.

What do you think ?


[1] https://github.com/gluster/glusterfs/issues/218

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