Bug 1529842 - Read-only listxattr syscalls seem to translate to non-read-only FOPs
Summary: Read-only listxattr syscalls seem to translate to non-read-only FOPs
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: GlusterFS
Classification: Community
Component: changelog
Version: mainline
Hardware: Unspecified
OS: Unspecified
urgent
high
Target Milestone: ---
Assignee: Aravinda VK
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-12-30 04:01 UTC by nh2
Modified: 2019-08-05 07:08 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-08-05 07:08:37 UTC
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:


Attachments (Terms of Use)

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.


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