<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body text="#000000" bgcolor="#ffffff">
<blockquote type="cite">
<pre>Try this to trigger self heal:
find <gluster-mount> -noleaf -print0 -name <file name>| xargs --null
stat >/dev/null
On Sun, May 15, 2011 at 11:20 AM, Martin Schenker
<<a href="http://gluster.org/cgi-bin/mailman/listinfo/gluster-users">martin.schenker at profitbricks.com</a>> wrote:
><i> Can someone enlighten me what's going on here? We have a two peers, the file
</i>><i> 21313 is shown through the client mountpoint as "1Jan1970", attribs on
</i>><i> server pserver3 don't match but NO self-heal or repair can be triggered
</i>><i> through "ls -alR"?!?
</i>><i>
</i>><i> Checking the files through the server mounts show that two versions are on
</i>><i> the system. But the wrong one (as with the "1Jan1970") seems to be the
</i>><i> preferred one by the client?!?
</i>><i>
</i>><i> Do I need to use setattr or what in order to get the client to see the RIGHT
</i>><i> version?!? This is not the ONLY file displaying this problematic behaviour!
</i>><i>
</i>><i> Thanks for any feedback.
</i>><i>
</i>><i> Martin
</i>><i>
</i>><i> pserver5:
</i>><i>
</i>><i> 0 <a href="http://gluster.org/cgi-bin/mailman/listinfo/gluster-users">root at pserver5</a>:~ # ls -al
</i>><i> /mnt/gluster/brick1/storage/images/2078/ebb83b05-3a83-9d18-ad8f-8542864da6ef
</i>><i> /hdd-images
</i>><i>
</i>><i> -rwxrwx--- 1 libvirt-qemu vcb 483183820800 May 13 13:41 21313
</i>><i>
</i>><i> 0 <a href="http://gluster.org/cgi-bin/mailman/listinfo/gluster-users">root at pserver5</a>:~ # getfattr -R -d -e hex -m "trusted.afr."
</i>><i> /mnt/gluster/brick1/storage/images/2078/ebb83b05-3a83-9d18-ad8f-8542864da6ef
</i>><i> /hdd-images/21313
</i>><i> getfattr: Removing leading '/' from absolute path names
</i>><i> # file:
</i>><i> mnt/gluster/brick1/storage/images/2078/ebb83b05-3a83-9d18-ad8f-8542864da6ef/
</i>><i> hdd-images/21313
</i>><i> trusted.afr.storage0-client-2=0x000000000000000000000000
</i>><i> trusted.afr.storage0-client-3=0x000000000000000000000000
</i>><i>
</i>><i> 0 <a href="http://gluster.org/cgi-bin/mailman/listinfo/gluster-users">root at pserver5</a>:~ # ls -alR
</i>><i> /opt/profitbricks/storage/images/2078/ebb83b05-3a83-9d18-ad8f-8542864da6ef/h
</i>><i> dd-images/21313
</i>><i> -rwxrwx--- 1 libvirt-qemu kvm 483183820800 Jan 1 1970
</i>><i> /opt/profitbricks/storage/images/2078/ebb83b05-3a83-9d18-ad8f-8542864da6ef/h
</i>><i> dd-images/21313
</i>><i>
</i>><i> pserver3:
</i>><i>
</i>><i> 0 <a href="http://gluster.org/cgi-bin/mailman/listinfo/gluster-users">root at pserver3</a>:~ # ls -al
</i>><i> /mnt/gluster/brick1/storage/images/2078/ebb83b05-3a83-9d18-ad8f-8542864da6ef
</i>><i> /hdd-images
</i>><i>
</i>><i> -rwxrwx--- 1 libvirt-qemu kvm 483183820800 Jan 1 1970 21313
</i>><i>
</i>><i> 0 <a href="http://gluster.org/cgi-bin/mailman/listinfo/gluster-users">root at pserver3</a>:~ # ls -alR
</i>><i> /opt/profitbricks/storage/images/2078/ebb83b05-3a83-9d18-ad8f-8542864da6ef/h
</i>><i> dd-images/21313
</i>><i> -rwxrwx--- 1 libvirt-qemu kvm 483183820800 Jan 1 1970
</i>><i> /opt/profitbricks/storage/images/2078/ebb83b05-3a83-9d18-ad8f-8542864da6ef/h
</i>><i> dd-images/21313
</i>><i>
</i>><i> 0 <a href="http://gluster.org/cgi-bin/mailman/listinfo/gluster-users">root at pserver3</a>:~ # getfattr -R -d -e hex -m "trusted.afr."
</i>><i> /mnt/gluster/brick1/storage/images/2078/ebb83b05-3a83-9d18-
</i>><i> ad8f-8542864da6ef/hdd-images/21313
</i>><i> getfattr: Removing leading '/' from absolute path names
</i>><i> # file:
</i>><i> mnt/gluster/brick1/storage/images/2078/ebb83b05-3a83-9d18-ad8f-8542864da6ef/
</i>><i> hdd-images/21313
</i>><i> trusted.afr.storage0-client-2=0x000000000000000000000000
</i>><i> trusted.afr.storage0-client-3=0x0b0000090900000000000000 <- mismatch,
</i>><i> should be targeted for self-heal/repair? Why is there a difference in the
</i>><i> views?
</i>><i>
</i>><i>
</i>><i> From the volfile:
</i>><i>
</i>><i> volume storage0-client-2
</i>><i> type protocol/client
</i>><i> option remote-host de-dc1-c1-pserver3
</i>><i> option remote-subvolume /mnt/gluster/brick1/storage
</i>><i> option transport-type rdma
</i>><i> option ping-timeout 5
</i>><i> end-volume
</i>><i>
</i>><i> volume storage0-client-3
</i>><i> type protocol/client
</i>><i> option remote-host de-dc1-c1-pserver5
</i>><i> option remote-subvolume /mnt/gluster/brick1/storage
</i>><i> option transport-type rdma
</i>><i> option ping-timeout 5
</i>><i> end-volume
</i>><i>
</i></pre>
</blockquote>
Hello All-<br>
I am seeing similar behaviour in two of my volumes, now using
GlusterFS version 3.2.2. There are files dated 1st Jan 1970 on one
brick, where the same files on the mirror brick have sensible date
stamps. In the cases I have investigated the date shown at the
mount point is 1st Jan 1970. However, unlike the problem initially
reported in this thread, I have not seen any xattr mismatches, as
illustrated by the example below.<br>
<br>
[root@bdan4 glusterfs]# ls -l
behemoth/aatsr/AT2_AVG_3PAARC19951229_D_nD2b.nc<br>
-rw-r--r-- 1 resc essc 381894 Jan 1 1970
behemoth/aatsr/AT2_AVG_3PAARC19951229_D_nD2b.nc<br>
[root@bdan4 glusterfs]# getfattr -R -d -e hex -m "trusted.afr."
behemoth/aatsr/AT2_AVG_3PAARC19951229_D_nD2b.nc<br>
# file: behemoth/aatsr/AT2_AVG_3PAARC19951229_D_nD2b.nc<br>
trusted.afr.marine-client-2=0x000000000000000000000000<br>
trusted.afr.marine-client-3=0x000000000000000000000000<br>
<br>
I have been using the following self heal method since it became the
recommended method shown in the GlusterFS documentation.<br>
<pre>find <gluster-mount> -noleaf -print0 -name <file name>| xargs --null
stat >/dev/null</pre>
Is there a better way to trigger self-healing, which would catch
these obvious modification time errors?<br>
<br>
-Dan.<br>
<pre class="moz-signature" cols="72">--
Mr. D.A. Bretherton
Computer System Manager
Environmental Systems Science Centre
Harry Pitt Building
3 Earley Gate
University of Reading
Reading, RG6 6AL
UK
Tel. +44 118 378 5205
Fax: +44 118 378 6413 </pre>
</body>
</html>