[Bugs] [Bug 1286970] Write-behind should serve the true file size in LOOKUP callback?

[bugzilla at redhat.com]

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

Raghavendra G <rgowdapp at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |CLOSED
         Depends On|                            |1390050
         Resolution|---                         |DUPLICATE
        Last Closed|                            |2017-02-09 23:42:47



--- Comment #1 from Raghavendra G <rgowdapp at redhat.com> ---
(In reply to Krutika Dhananjay from comment #0)
> Description of problem:
> 
> As part of reviewing http://review.gluster.org/#/c/12594/, figured
> write-behind translator does not implement LOOKUP fop. In the event of a
> "revalidate" LOOKUP on a file while writes on it are still held by
> write-behind from being flushed, once the fop hits the disk, in its return
> path the postbuf might still contain the old file size and other attributes
> (to the application it is as if the writes it had sent never happened on
> this file in the first place). This could *possibly* lead to errors if
> md-cache stores the old(er) attributes and serves them as part of (f)stat,
> subsequent lookups etc. Md-cache also uses iatts from LINK and UNLINK
> callbacks, both of which are unimplemented in write-behind.
> 
> I haven't tested this theory on an actual volume. It is also quite possible
> that I am missing something important in some other part of the code. Adding
> Raghavendra G in CC list in any case.
> 
> @Raghavendra: Feel free to close this bug if the theory is not valid. :)

No. Your theory is very much valid :). We've fixed this as part of bz 1390050

> 
> Version-Release number of selected component (if applicable):
> 
> 
> How reproducible:
> 
> 
> Steps to Reproduce:
> 1.
> 2.
> 3.
> 
> Actual results:
> 
> 
> Expected results:
> 
> 
> Additional info:

*** This bug has been marked as a duplicate of bug 1390050 ***


Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1390050
[Bug 1390050] Elasticsearch get CorruptIndexException errors when running
with GlusterFS persistent storage
-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.