Bug 928919

Summary: Extended attributes are being written after fsync() call
Product: [Red Hat Storage] Red Hat Gluster Storage Reporter: Peter Portante <pportant>
Component: gluster-swiftAssignee: Luis Pabón <lpabon>
Status: CLOSED ERRATA QA Contact: pushpesh sharma <psharma>
Severity: low Docs Contact:
Priority: low    
Version: 2.0CC: bbandari, lpabon, madam, rhs-bugs, surs
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-09-23 22:32:28 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:    
Bug Blocks: 903396, 978061    

Description Peter Portante 2013-03-28 17:55:47 UTC
The write_metadata() call, which eventually invokes lsetxattr(), is being called *after* the os.fsync() call in the PDQ bits. This can lead to data loss as the attributes are not necessarily flushed then.

Comment 2 Luis Pabón 2013-07-12 18:39:44 UTC
Is this still an issue in G4S?  Can we close this bug?

Comment 3 Luis Pabón 2013-07-17 01:01:12 UTC
RHS 2.0 UFO Bugs are being set to low priority.

Comment 4 Sachidananda Urs 2013-08-20 12:39:38 UTC
Hi Luis, was there any patch that fixed this? How was this fixed?

Comment 5 pushpesh sharma 2013-08-26 07:58:08 UTC
As evident from object-server strace, fsetxattr() is called before fsync() system call.So the problem seems to be fixed with RHS2.1 ,Marking this as verified, based on this observation. 

[root@dhcp207-149 ~]# rpm -qa|grep swift
gluster-swift-1.8.0-6.11.el6rhs.noarch
gluster-swift-account-1.8.0-6.11.el6rhs.noarch
gluster-swift-proxy-1.8.0-6.11.el6rhs.noarch
gluster-swift-object-1.8.0-6.11.el6rhs.noarch
gluster-swift-plugin-1.8.0-6.el6rhs.noarch
python-swiftclient-1.4.0-1.el6.noarch
gluster-swift-container-1.8.0-6.11.el6rhs.noarch
[root@dhcp207-149 ~]# 




[pid  3581] write(11, "Installing libgcc-4.4.7-3.el6.x8"..., 25045) = 25045 <0.000139>
[pid  3581] gettimeofday({1377503115, 769967}, NULL) = 0 <0.000006>
[pid  3581] gettimeofday({1377503115, 770017}, NULL) = 0 <0.000023>
[pid  3581] gettimeofday({1377503115, 770116}, NULL) = 0 <0.000001>
[pid  3581] fsetxattr(11, "user.swift.metadata", "\x80\x02}q\x01(U\x0eContent-Lengthq\x02U\x0525045q\x03U\x04ETagq\x04U 073741db64c51df70e776d4e0be6d151q\x05U\x0bX-Timestampq\x06U\x101377503115.75817q\x07U\x0dX-Object-Typeq\x08U\x04fileq\x09U\x06X-Typeq\x0aU\x06Objectq\x0bU\x0cContent-Typeq\x0cU\x18application/octet-streamq\x0du.", 203, 0) = 0 <0.004774>
[pid  3581] futex(0x7f4fdc001660, FUTEX_WAKE_PRIVATE, 1) = 1 <0.000031>
[pid  3610] <... futex resumed> )       = 0 <17.091442>
[pid  3581] poll([{fd=12, events=POLLIN|POLLPRI|POLLERR|POLLHUP}, {fd=7, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 2, 60000 <unfinished ...>
[pid  3610] fsync(11)                   = 0 <0.058055>
[pid  3610] write(13, " ", 1)           = 1 <0.000017>
[pid  3610] futex(0x7f4fdc001660, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid  3581] <... poll resumed> )        = 1 ([{fd=12, revents=POLLIN}]) <0.058238>
[pid  3581] read(12, " ", 1)            = 1 <0.000007>
[pid  3581] gettimeofday({1377503115, 833523}, NULL) = 0 <0.000006>
[pid  3581] read(12, 0x256f8c4, 1)      = -1 EAGAIN (Resource temporarily unavailable) <0.000006>
[pid  3581] gettimeofday({1377503115, 833615}, NULL) = 0 <0.000006>
[pid  3581] fadvise64(11, 0, 25045, POSIX_FADV_DONTNEED) = 0 <0.000012>
[pid  3581] rename("/mnt/gluster-object/test2/dir/.install.log.sys.12344b4a7e14c38f57b6a34c37079918", "/mnt/gluster-object/test2/dir/install.log.sys") = 0 <0.003343>

Comment 6 Scott Haines 2013-09-23 22:32:28 UTC
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. 

For information on the advisory, and where to find the updated files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-1262.html