Bug 1286970 - Write-behind should serve the true file size in LOOKUP callback?
Write-behind should serve the true file size in LOOKUP callback?
Status: CLOSED DUPLICATE of bug 1390050
Product: GlusterFS
Classification: Community
Component: write-behind (Show other bugs)
mainline
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: bugs@gluster.org
: Triaged
Depends On: 1390050
Blocks:
  Show dependency treegraph
 
Reported: 2015-12-01 04:24 EST by Krutika Dhananjay
Modified: 2017-02-09 23:44 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-02-09 23:42:47 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Krutika Dhananjay 2015-12-01 04:24:43 EST
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-09 23:42:47 EST
(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-09 23:44:42 EST
http://review.gluster.org/15757

Note You need to log in before you can comment on or make changes to this bug.