Bug 1286970

Summary: Write-behind should serve the true file size in LOOKUP callback?
Product: [Community] GlusterFS Reporter: Krutika Dhananjay <kdhananj>
Component: write-behindAssignee: bugs <bugs>
Status: CLOSED DUPLICATE QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: mainlineCC: bugs, rgowdapp
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-02-10 04:42:47 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1390050    
Bug Blocks:    

Description Krutika Dhananjay 2015-12-01 09:24:43 UTC
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:

Comment 1 Raghavendra G 2017-02-10 04:42:47 UTC
(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 ***

Comment 2 Raghavendra G 2017-02-10 04:44:42 UTC
http://review.gluster.org/15757