Bug 1286970
Summary: | Write-behind should serve the true file size in LOOKUP callback? | ||
---|---|---|---|
Product: | [Community] GlusterFS | Reporter: | Krutika Dhananjay <kdhananj> |
Component: | write-behind | Assignee: | bugs <bugs> |
Status: | CLOSED DUPLICATE | QA Contact: | |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | mainline | CC: | 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
(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 *** |