Description of problem: Appending to a file via redirection ">>" does not update the atime,ctime, mtime on files that it redirected to. All other methods seem to work correctly which includes: user space apps(emacs), and ">" redirection. Customer is using ">>" to append to files. When they append to the file with ">>" the timestamps are not updated on local or remote nodes which is a problem because they use timestamps to see when file was last updated. Version-Release number of selected component (if applicable): Recreated on xen virtual machine with shared disk file image. kmod-gfs2 is not installed. $ rpm -qa | grep kmod kmod-gfs-xen-0.1.23-5.el5_2.4 kmod-gfs-xen-0.1.31-3.el5 $ uname -a Linux rh5node1 2.6.18-128.1.6.el5xen #1 SMP Tue Mar 24 12:28:27 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux How reproducible: The reproduciable seems to create most of the time, however there are times when it does recreate exactly. Steps to Reproduce: 1. date; echo "Hello Create" > /mnt/gfstest/readme.txt; \ sleep 60; stat /mnt/gfstest/readme.txt; echo ""; \ echo "DATE: $(date)"; 2. date; echo "Hello Appending" >> /mnt/gfstest/readme.txt; \ sleep 60; stat /mnt/gfstest/readme.txt; echo ""; \ echo "DATE: $(date)"; Actual results: The atime, ctime, mtime fields are not updated when you stat the file.However, sometimes the local notes gets ctime, mtime stat fields updated and the remote nodes do not and atime is not updated on any node. Expected results: atime, ctime, mtime should all be updated. Additional info: GFS1 will update atime, ctime, mtime correctly. I have also tried setting "demote_secs" to 10 and yielded same results. Tried mounting with relatime and the option would not apply, based on article: http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Global_File_System_2/s1-manage-atimeconf.html#s2-manage-mountrelatime $ mount -t gfs2 /dev/sda1 /mnt/gfstest -o relatime /sbin/mount.gfs2: error mounting /dev/sda1 on /mnt/gfstest: Invalid argument
Is this a GFS1 bug only or GFS2 as well? (The summary seems to suggest a GFS2 complaint)
Is the time on the nodes synchronised with (for example) NTP and has it managed to actually pull the nodes in to having the same time on each? If not, then you will see strange things happening with the timestamps.
These machines do not use NTP and their time is within a few seconds of each other. GFS1 seems to work correctly. GFS1 will update the flags correctly on ">>" redirection of data to append to a file. --sbradley This event sent from IssueTracker by sbradley issue 274685
This doesn't relate to atime, so adjusting the summary line.
Created attachment 342669 [details] Patch to update times
Created attachment 342716 [details] second attempt patch
+ gfs2_dinode_out(ip, (void*) di); does not need a cast to void. It takes a void pointer anyway. Also we should check page_mkwrite at the same time to ensure that it updates the timestamps correctly if thats required. Again a comparison with ext3 would be sensible.
Created attachment 343615 [details] RHEL5 patch that also fixes mmap atime update
Created attachment 343616 [details] Upstream patch (does not contain the mmap atime update bit as it is already upstream)
sbradley, could you try out the patch in comment #8 and tell me if it works ok?
Posted patch in comment #8 to rhkernel-list for inclusion in RHEL 5.5.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
in kernel-2.6.18-168.el5 You can download this test kernel from http://people.redhat.com/dzickus/el5 Please do NOT transition this bugzilla state to VERIFIED until our QE team has sent specific instructions indicating when to do so. However feel free to provide a comment indicating that this fix has been verified.
~~ Attention Customers and Partners - RHEL 5.5 Beta is now available on RHN ~~ RHEL 5.5 Beta has been released! There should be a fix present in this release that addresses your request. Please test and report back results here, by March 3rd 2010 (2010-03-03) or sooner. Upon successful verification of this request, post your results and update the Verified field in Bugzilla with the appropriate value. If you encounter any issues while testing, please describe them and set this bug into NEED_INFO. If you encounter new defects or have additional patch(es) to request for inclusion, please clone this bug per each request and escalate through your support representative.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2010-0178.html