Bug 1529842

Summary: Read-only listxattr syscalls seem to translate to non-read-only FOPs
Product: [Community] GlusterFS Reporter: nh2 <nh2-redhatbugzilla>
Component: changelogAssignee: Aravinda VK <avishwan>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: high Docs Contact:
Priority: urgent    
Version: mainlineCC: atumball, bugs, khiremat, nh2-redhatbugzilla, sacharya, sunkumar, vbellur
Target Milestone: ---Keywords: Performance
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-08-05 07:08:37 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:

Description nh2 2017-12-30 04:01:22 UTC
Description of problem:

I'm running Gluster 3.12.3 on Linux (NixOS).

When I use

  getfattr /my/glustermount/myfile

which does a `listxattr()` syscall, then glusterfs translates this to a pair of SETATTR/REMOVEXATTR FOPs that appear in CHANGELOG.* files, for example

    # cat /var/var/lib/misc/glusterfsd/glusterfind/myvol/myvolume/20171229-213130-082373-0RsA37/eef7fa430d9ab60e74ec72b66629f783f9fb37fa/.history/.current/CHANGELOG.1512988094
    M 588ddd06-ca1f-48bc-b5ea-eece0e407b3d SETATTR
    M 588ddd06-ca1f-48bc-b5ea-eece0e407b3d REMOVEXATTR

Should really any SETATTR FOP be issued on the gluster side given that `listxattr()` is a read-only operation?

This makes performance problems:

My backup tool (bup) that I use for backing up my volume issues a `llistxattr()` for each file it encounters, thus creating millions of SETATTR/REMOVEXATTR pairs in CHANGELOG.* files and blowing up the work that `glusterfind` has to do to process them a lot.

How reproducible: Always

Steps to Reproduce:
1. Make sure changelog xlator is enabled (e.g. run glusterfind)
2. Monitor CHANGELOG entries, e.g. using: while true; do cat /data/glusterfs/myvol/brick1/brick/.glusterfs/changelogs/CHANGELOG.$(date '+%s' && sleep 1); sleep 0.1; done
3. Run `getfattr` on a file in the mount

Actual results:

SETATTR/REMOVEXATTR appears in the changelog.

Expected results:

SETATTR/REMOVEXATTR does not appear in the changelog.

Comment 1 Aravinda VK 2019-06-18 13:29:39 UTC
I tested in my setup with fresh volume and changelog enabled. The issue is not reproducible.

Please try again and provide the reproducer.

[root@f29 ~]# gluster volume create gv1 replica 3 f29.sonne:/bricks/gv1/b1 f29.sonne:/bricks/gv1/b2 f29.sonne:/bricks/gv1/b3 force
[root@f29 ~]# gluster volume start gv1
[root@f29 ~]# gluster volume set gv1 changelog.changelog on
[root@f29 ~]# mount -t glusterfs localhost:gv1 /mnt/gv1
[root@f29 ~]# echo "Hello World" > /mnt/gv1/myfile
[root@f29 ~]# sleep 20  # Sleep 20 to wait for changelog rollover
[root@f29 ~]# for f in `ls ./gluster-changelog-parser /bricks/gv1/b1/.glusterfs/changelogs/CHANGELOG.*`;do echo $f;./gluster-changelog-parser $f; done
/bricks/gv1/b1/.glusterfs/changelogs/CHANGELOG.1560862886
E d4b3e7c7-8ef1-4327-8117-0a01af0bf1ed CREATE   33188 0 0 00000000-0000-0000-0000-000000000001/myfile
D d4b3e7c7-8ef1-4327-8117-0a01af0bf1ed 

[root@f29 ~]# getfattr -d -m . /mnt/gv1/myfile 
getfattr: Removing leading '/' from absolute path names
# file: mnt/gv1/myfile
security.selinux="system_u:object_r:fusefs_t:s0"

[root@f29 ~]# sleep 20
[root@f29 ~]# for f in `ls ./gluster-changelog-parser /bricks/gv1/b1/.glusterfs/changelogs/CHANGELOG.*`;do echo $f;./gluster-changelog-parser $f; done
/bricks/gv1/b1/.glusterfs/changelogs/CHANGELOG.1560862886
E d4b3e7c7-8ef1-4327-8117-0a01af0bf1ed CREATE   33188 0 0 00000000-0000-0000-0000-000000000001/myfile
D d4b3e7c7-8ef1-4327-8117-0a01af0bf1ed

I used gluster-changelog-parser(https://github.com/aravindavk/gluster-changelog-parser) to read Changelogs.

Comment 2 nh2 2019-06-20 21:10:40 UTC
Did you use the same version as I was using, 3.12.3?

Unfortunately I won't be able to put time into re-reproducing this, as we switched to Ceph a year ago.

Comment 3 Aravinda VK 2019-08-05 07:08:37 UTC
(In reply to nh2 from comment #2)
> Did you use the same version as I was using, 3.12.3?
> 
> Unfortunately I won't be able to put time into re-reproducing this, as we
> switched to Ceph a year ago.

Thanks for the update. Closing this bug since the issue is not reproducible in the latest version, as mentioned in Comment 1. Please reopen if found again.