Bug 811976 - [6a995ab3300a5ee0ee79a4d7d75281a79deec96e] zero byte files when a file is replaced with the same string in a loop
Summary: [6a995ab3300a5ee0ee79a4d7d75281a79deec96e] zero byte files when a file is rep...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: GlusterFS
Classification: Community
Component: quick-read
Version: mainline
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Raghavendra G
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: 817967
TreeView+ depends on / blocked
 
Reported: 2012-04-12 12:50 UTC by Anush Shetty
Modified: 2015-12-01 16:45 UTC (History)
3 users (show)

Fixed In Version: glusterfs-3.4.0
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-07-24 17:42:03 UTC
Regression: ---
Mount Type: fuse
Documentation: ---
CRM:
Verified Versions:
Embargoed:


Attachments (Terms of Use)

Description Anush Shetty 2012-04-12 12:50:58 UTC
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 14:07:47 UTC
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. 

Anush,

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

regards,
Raghavendra

Comment 2 Anush Shetty 2012-04-15 02:50:20 UTC
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 07:00:28 UTC
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)

Comment 4 Anush Shetty 2012-04-18 12:00:48 UTC
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.