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. :) Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
(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 ***
http://review.gluster.org/15757