<!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 bgcolor="#ffffff" text="#000000">
<b>
<blockquote type="cite"><b>Luis Cerezo</b> <a
href="mailto:gluster-users%40gluster.org?Subject=Re%3A%20%5BGluster-users%5D%20Anyone%20have%20that%20find%20command%20handy&In-Reply-To=%3C3F7AF906-46B9-4166-8F6D-5400FB0B7EE9%40luiscerezo.org%3E"
title="[Gluster-users] Anyone have that find command handy">lec
at luiscerezo.org </a><br>
<i>Thu Jul 21 17:19:45 PDT 2011</i>
<hr>
<pre>i would also add a -size 0.
-luis
<blockquote type="cite"><pre>On Jul 21, 2011, at 9:30 AM, Joe Landman wrote:
><i> On 07/21/2011 11:21 AM, Joe Landman wrote:
</i>>><i> On 07/21/2011 11:17 AM, Burnash, James wrote:
</i>>>><i> Hi Joe.
</i>>>><i>
</i>><i>
</i>><i> Found it:
</i>><i>
</i>><i> find $local -type f -perm +01000 -exec rm -v '{}' \;
</i>><i>
</i>><i> for $local
</i>><i>
</i>><i> </i></pre>
</blockquote>
</pre>
</blockquote>
</b><font size="-1">I too would strongly suggest this, because I
have been seeing real, non-zero size files with "<span
style="font-size: 11pt; font-family: Arial; color: rgb(0, 0, 0);
background-color: transparent; font-weight: normal; font-style:
normal; font-variant: normal; text-decoration: none;
vertical-align: baseline;">---------T" permissions since
upgrading to 3.2.0. These files are visible at the mount point
and usually (although not always) have the correct ownership
(i.e. non root). In each case there is always a different
version of the file on another pair of bricks, which is
different in size and almost always older than the 'T' file (as
I call them), but I did see one case where the alternative
version was newer than the 'T' file. I have only seen a few
dozen of these so far, but what worries me is that GlusterFS
could be deleting them as if they are "stale link files", a
message I often see in the client logs.<br>
<br>
I have no idea which of the two alternative versions of these
files are correct - the 'T' files or their alternatives -
possibly both. They might both be valid output from two
successive model runs for example. Only the owners of these
files can say which versions are correct; one user has agreed to
take a look at some examples that I saved but hasn't had time to
do it yet. Deleting a 'T' file (or moving it to another
location as I always do) results in the alternative version
appearing at the mount point. The same thing happens after
removing the trusted.gfid xattr from the 'T' file, as is done to
files with GFID errors by Vikas Gorur's new GFID mismatch fixing
tools I believe. Therefore there is a real danger of 'T' files
being deleted, either by "find ... -exec<font face="Verdana"> rm</font></span></font><font
face="Verdana" size="-1"> {} \;" or by GlusterFS itself</font><font
size="-1">, resulting in the loss of important data. What
certainly does happen is that some of the 'T' files become hidden
from the mount point (possibly as a result of GFID matcher fixer
scripts), and even if they are not actually deleted it can be just
as disruptive for the files' owners.<br>
<br>
I sincerely hope that the GFID bug fixes in 3.2.2 will stop this
from occurring, but I don't know if the 'T' file problem is
related to GFID mismatches and it is too early to tell whether or
not the problem has been solved by upgrading to 3.2.2. I am going
to monitor the situation by doing "find . -perm 1000 -size +0b
-exec /bin/ls -l {} \;" in the mount points of all the volumes,
and on the back-end filesystems, as often as I can.<br>
<br>
-Dan.<br>
</font><span style="font-size: 11pt; font-family: Arial; color:
rgb(0, 0, 0); background-color: transparent; font-weight: normal;
font-style: normal; font-variant: normal; text-decoration: none;
vertical-align: baseline;"></span><br>
<pre>
<i>
</i></pre>
<br>
</body>
</html>