Bug 782388 - [3.3.0qa19] Read succeeds but exit status non-zero
Summary: [3.3.0qa19] Read succeeds but exit status non-zero
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: GlusterFS
Classification: Community
Component: quick-read
Version: mainline
Hardware: x86_64
OS: Linux
high
medium
Target Milestone: ---
Assignee: Raghavendra G
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-01-17 11:10 UTC by Anush Shetty
Modified: 2012-03-19 04:45 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-03-19 04:45:03 UTC
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:


Attachments (Terms of Use)

Description Anush Shetty 2012-01-17 11:10:45 UTC
Description of problem: When I am writing into a file from 1 client and reading the file from the other, sometimes the read succeeds with a non-zero exit status.


Version-Release number of selected component (if applicable): 3.3.0qa19

How reproducible:

On client1: while true; do echo 'sdsd' > dot; sleep 1; rm -rf dot; done

On client2: cat dot


Actual results:

# cat dot
sdsd
cat: dot: No such file or directory


Additional info:

When quick-read was disabled, this issue was not reproducible.

Strace output-
open("/usr/lib/locale/locale-archive", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=8363680, ...}) = 0
mmap(NULL, 8363680, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fec2df40000
close(3)                                = 0
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 8), ...}) = 0
open("dot", O_RDONLY)                   = 3
fstat(3, {st_mode=S_IFREG|0640, st_size=5, ...}) = 0
mmap(NULL, 139264, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fec2ecd5000
read(3, "sdsd\n", 131072)               = 5
write(1, "sdsd\n", 5)                   = 5
read(3, 0x7fec2ecd6000, 131072)         = -1 ENOENT (No such file or directory)
write(2, "cat: ", 5cat: )                    = 5
write(2, "dot", 3dot)                      = 3
open("/usr/share/locale/locale.alias", O_RDONLY) = 4
fstat(4, {st_mode=S_IFREG|0644, st_size=2570, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fec2ecd4000
read(4, "# Locale name alias data base.\n#"..., 4096) = 2570
read(4, "", 4096)                       = 0
close(4)                                = 0
munmap(0x7fec2ecd4000, 4096)            = 0

Comment 1 Raghavendra G 2012-03-19 04:45:03 UTC
This seems to be a cache-coherency issue.Consider following sequence of events:

1.file was cached during lookup on client1,
2.file was deleted on client2. 
3.During first read, cache-timeout did not happen (1 sec is default timeout) and hence file was served from quick-read cache.
4.However, during second read, timeout did happen and validation was failed since file was removed from client2.

If one doesn't wants to run into cache-coherency issues, its advised to set the cache-timeout to zero.

Closing this bug for now.

regards,
Raghavendra.


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