Bug 928919 - Extended attributes are being written after fsync() call
Extended attributes are being written after fsync() call
Status: CLOSED ERRATA
Product: Red Hat Gluster Storage
Classification: Red Hat
Component: gluster-swift (Show other bugs)
2.0
x86_64 Linux
low Severity low
: ---
: ---
Assigned To: Luis Pabón
pushpesh sharma
:
Depends On:
Blocks: 903396 978061
  Show dependency treegraph
 
Reported: 2013-03-28 13:55 EDT by Peter Portante
Modified: 2016-11-08 17:24 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-09-23 18:32:28 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Peter Portante 2013-03-28 13:55:47 EDT
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 14:39:44 EDT
Is this still an issue in G4S?  Can we close this bug?
Comment 3 Luis Pabón 2013-07-16 21:01:12 EDT
RHS 2.0 UFO Bugs are being set to low priority.
Comment 4 Sachidananda Urs 2013-08-20 08:39:38 EDT
Hi Luis, was there any patch that fixed this? How was this fixed?
Comment 5 pushpesh sharma 2013-08-26 03:58:08 EDT
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 18:32:28 EDT
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

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