Bug 811976 - [6a995ab3300a5ee0ee79a4d7d75281a79deec96e] zero byte files when a file is replaced with the same string in a loop
[6a995ab3300a5ee0ee79a4d7d75281a79deec96e] zero byte files when a file is rep...
Product: GlusterFS
Classification: Community
Component: quick-read (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Raghavendra G
Depends On:
Blocks: 817967
  Show dependency treegraph
Reported: 2012-04-12 08:50 EDT by Anush Shetty
Modified: 2015-12-01 11:45 EST (History)
3 users (show)

See Also:
Fixed In Version: glusterfs-3.4.0
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-07-24 13:42:03 EDT
Type: Bug
Regression: ---
Mount Type: fuse
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Anush Shetty 2012-04-12 08:50:58 EDT
Description of problem: When the contents in a file was replaced with the same string using perl script, it resulted in a zero byte file after a few iterations

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

How reproducible: Consistently

Steps to Reproduce:
1. echo 'test' > dot
2. while true; do perl -i -pe 's/test/test/' dot; done
3. cat dot
Actual results: Returns ENOENT

# ls -lh dot
-rw-r--r-- 1 root root 0 2012-04-12 18:19 dot

Additional info:

This issue was not seen when quick-read was disabled.
Comment 1 Raghavendra G 2012-04-14 10:07:47 EDT
This is most likely not a bug. Following is the strace output of perl string replacement in action:

17197 open("file", O_RDONLY)            = 3
17197 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffb4696cd8) = -1 ENOSYS (Function not implemented)
17197 lseek(3, 0, SEEK_CUR)             = 0
17197 fstat(3, {st_mode=S_IFREG|0600, st_size=5, ...}) = 0
17197 fcntl(3, F_SETFD, FD_CLOEXEC)     = 0
17197 unlink("file")                    = 0
17197 open("file", O_WRONLY|O_CREAT|O_EXCL, 0600) = 4
17197 ioctl(4, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffb4696cd8) = -1 ENOSYS (Function not implemented)
17197 lseek(4, 0, SEEK_CUR)             = 0
17197 fstat(4, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
17197 fcntl(4, F_SETFD, FD_CLOEXEC)     = 0
17197 fstat(4, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
17197 fchmod(4, 0100600)                = 0
17197 read(3, "test\n", 4096)           = 5
17197 read(3, "", 4096)                 = 0
17197 write(4, "test\n", 5)             = 5
17197 close(4)                          = 0
17197 close(3)                          = 0

As can be seen, original file is unlinked and a new file is created and original file content after replacement is written into new file. However if the perl is interrupted between the window where a new file is created and content is written to it, we might see a file with no content. I am assuming that this is what has happened in this case. 


Are you sure that you interrupted the infinite loop doing string replacement only after perl completes its execution?

Comment 2 Anush Shetty 2012-04-14 22:50:20 EDT
I didn't interrupt the infinite loop in which the perl script was being executed. The perl script errored out with ENOENT after a while. When I checked the size, it was zero bytes.
Comment 3 Anand Avati 2012-04-18 03:00:28 EDT
CHANGE: http://review.gluster.com/3151 (performance/quick-read: disable reading from cache if unlink has happened after fd was opened.) merged in master by Vijay Bellur (vijay@gluster.com)
Comment 4 Anush Shetty 2012-04-18 08:00:48 EDT
Verified with 7ef32ae76d1c1e4a5ff47899d175be9fdeb73bc8. Don't see this issue now.

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