[Gluster-users] file changed as we read it

[Richard Neuboeck]

Hi,

I'm experiencing a problem that existed in gluster 3.7. When I
creating a (large) tar archive of brand new files I get a lot of
'file changed as we read it'. Further attempts to create archives
from the same source work without error messages.

Googling about this I found bug reports for 3.7 and other sites
(i.e.
http://lists.gluster.org/pipermail/gluster-users/2015-September/023641.html)
that also mentioned as solution to set cluster.consistent-metadata
to on.

So I did. Just in case I rebooted the servers and workstation but
still the problem persists.

The gluster volume is replica 3 and used as home share and accessed
with the FUSE gluster client only.

Here are the steps to reproduce the problem. The archive is ~16M. I
could reproduce it with any large archive.

$ tar xzf ViennaRNA-2.3.5.tar.gz
$ tar czf test.tar.gz ViennaRNA-2.3.5.tar.gz
...
tar: ViennaRNA-2.3.5/src/Kinfold/README: file changed as we read it
tar: ViennaRNA-2.3.5/src/Kinfold/AUTHORS: file changed as we read it
tar: ViennaRNA-2.3.5/m4/ltoptions.m4: file changed as we read it
tar: ViennaRNA-2.3.5/m4/ax_openmp.m4: file changed as we read it
tar: ViennaRNA-2.3.5/m4/ax_append_flag.m4: file changed as we read it
tar: ViennaRNA-2.3.5/m4/ac_rna_macros.m4: file changed as we read it
tar: ViennaRNA-2.3.5/m4/ac_rna_refman.m4: file changed as we read it
tar: ViennaRNA-2.3.5/m4/ax_check_link_flag.m4: file changed as we
read it
tar: ViennaRNA-2.3.5/m4/ac_rna_unit_tests.m4: file changed as we read it
tar: ViennaRNA-2.3.5/m4/ac_rna_swig.m4: file changed as we read it
tar: ViennaRNA-2.3.5/packaging/win_installer_fedora_i686.nsi.in:
file changed as we read it
tar: ViennaRNA-2.3.5/packaging/macosx/resources/ohm.png: file
changed as we read it
tar: ViennaRNA-2.3.5/packaging/macosx/resources/welcome.txt.in: file
changed as we read it
tar:
ViennaRNA-2.3.5/packaging/win_installer_archlinux_x86_64.nsi.in:
file changed as we read it
tar: ViennaRNA-2.3.5/config.sub: file changed as we read it
tar: ViennaRNA-2.3.5/README: file changed as we read it
...

Our servers are running CentOS 7 and the latest gluster CBS
packages: glusterfs-server-3.12.1-2.el7.x86_64

# gluster volume get home cluster.consistent-metadata
Option                                  Value

------                                  -----

cluster.consistent-metadata             on

# gluster volume info home

Volume Name: home
Type: Replicate
Volume ID: fe6218ae-f46b-42b3-a467-5fc6a36ad48a
Status: Started
Snapshot Count: 1
Number of Bricks: 1 x 3 = 3
Transport-type: tcp
Bricks:
Brick1: sphere-six:/srv/gluster_home/brick
Brick2: sphere-five:/srv/gluster_home/brick
Brick3: sphere-four:/srv/gluster_home/brick
Options Reconfigured:
features.quota-deem-statfs: on
features.inode-quota: on
features.quota: on
cluster.readdir-optimize: on
cluster.lookup-optimize: on
performance.client-io-threads: on
performance.cache-size: 1GB
network.inode-lru-limit: 90000
performance.md-cache-timeout: 600
performance.cache-invalidation: on
performance.cache-samba-metadata: on
performance.stat-prefetch: on
features.cache-invalidation-timeout: 600
features.cache-invalidation: on
transport.address-family: inet
performance.readdir-ahead: on
nfs.disable: on
cluster.server-quorum-type: server
cluster.quorum-type: auto
features.barrier: disable
cluster.consistent-metadata: on
cluster.localtime-logging: enable
cluster.server-quorum-ratio: 51%

Clients are Fedora 26, also running the latest distribution shipped
gluster package: glusterfs-3.10.6-4.fc26.x86_64

There are no errors or warnings in the log files on either server or
workstation.

As it seems the meta data is not in sync is there anything else I
can do to make sure the meta data is synchronized?

Thanks for you help!
Cheers
Richard

-- 
/dev/null

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.gluster.org/pipermail/gluster-users/attachments/20171114/0f62377c/attachment.sig>