<div dir="ltr">Justin,<div>What you are seeing are internal DHT linkfiles. They are zero byte files with mode 01000. Changing their mode forcefully in the backend to something else WILL render your files inaccessible from the mount point. I am assuming that you have seen these files only in the backend and not from the mount point. And accessing/modifying files like this directly from the backend is very dangerous for your data, as explained in this very example.</div>
<div><br></div><div>Avati<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 1, 2013 at 2:25 PM, Justin Dossey <span dir="ltr"><<a href="mailto:jbd@podomatic.com" target="_blank">jbd@podomatic.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">One thing I do see with the issue we're having is that the files which have lost their permissions have "bad" versions on multiple bricks. Since the replica count is 2 for any given file, there should be only two copies of each, no? <div>
<div><br></div><div>For example, the file below has zero-length, zero-permission versions on uds06/brick2 and uds-07/brick2, but good versions on uds-05/brick1 and uds-06/brick1.</div><div><div><br></div><div><div>FILE is /09/38/1f/eastar/mail/entries/trash/2008-07-06T13_41_56-07_00.dump</div>
<div>uds-05 -rw-r--r-- 2 apache apache 2233 Jul 6 2008 /export/brick1/vol1/09/38/1f/eastar/mail/entries/trash/2008-07-06T13_41_56-07_00.dump</div><div>uds-06 -rw-r--r-- 2 apache apache 2233 Jul 6 2008 /export/brick1/vol1/09/38/1f/eastar/mail/entries/trash/2008-07-06T13_41_56-07_00.dump</div>
<div>uds-06 ---------T 2 apache apache 0 Jul 23 03:11 /export/brick2/vol1/09/38/1f/eastar/mail/entries/trash/2008-07-06T13_41_56-07_00.dump</div><div>uds-07 ---------T 2 apache apache 0 Jul 23 03:11 /export/brick2/vol1/09/38/1f/eastar/mail/entries/trash/2008-07-06T13_41_56-07_00.dump</div>
</div><div><br></div></div></div><div>Is it acceptable for me to just delete the zero-length copies?</div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">
On Thu, Aug 1, 2013 at 12:57 PM, Justin Dossey <span dir="ltr"><<a href="mailto:jbd@podomatic.com" target="_blank">jbd@podomatic.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Do you know whether it's acceptable to modify permissions on the brick itself (as opposed to over NFS or via the fuse client)? It seems that as long as I don't modify the xattrs, the permissions I set on files on the bricks are passed through.</div>
<div><div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 1, 2013 at 12:32 PM, Joel Young <span dir="ltr"><<a href="mailto:jdy@cryregarder.com" target="_blank">jdy@cryregarder.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I am not seeing exactly that, but I am experiencing the permission for<br>
the root directory of a gluster volume reverting from a particular<br>
user.user to root.root ownership. I have to periodically do a "cd<br>
/share; chown user.user . "<br>
<div><div><br>
On Thu, Aug 1, 2013 at 12:25 PM, Justin Dossey <<a href="mailto:jbd@podomatic.com" target="_blank">jbd@podomatic.com</a>> wrote:<br>
> Hi all,<br>
><br>
> I have a relatively-new GlusterFS 3.3.2 4-node cluster in<br>
> distributed-replicated mode running in a production environment.<br>
><br>
> After adding bricks from nodes 3 and 4 (which changed the cluster type from<br>
> simple replicated-2 to distributed-replicated-2), I've discovered that files<br>
> are randomly losing their permissions. These are files that aren't being<br>
> accessed by our clients-- some of them haven't been touched for years.<br>
><br>
> When I say "losing their permissions", I mean that regular files are going<br>
> from 0644 to 0000 or 1000.<br>
><br>
> Since this is a real production issue, I run a parallel find process to<br>
> correct them every ten minutes. It has corrected approximately 40,000 files<br>
> in the past 18 hours.<br>
><br>
> Is anyone else seeing this kind of issue? My searches have turned up<br>
> nothing so far.<br>
><br>
> --<br>
> Justin Dossey<br>
> CTO, PodOmatic<br>
><br>
><br>
</div></div>> _______________________________________________<br>
> Gluster-users mailing list<br>
> <a href="mailto:Gluster-users@gluster.org" target="_blank">Gluster-users@gluster.org</a><br>
> <a href="http://supercolony.gluster.org/mailman/listinfo/gluster-users" target="_blank">http://supercolony.gluster.org/mailman/listinfo/gluster-users</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Justin Dossey<br>CTO, PodOmatic<div><br></div>
</div>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Justin Dossey<br>CTO, PodOmatic<div><br></div>
</div>
</div></div><br>_______________________________________________<br>
Gluster-users mailing list<br>
<a href="mailto:Gluster-users@gluster.org">Gluster-users@gluster.org</a><br>
<a href="http://supercolony.gluster.org/mailman/listinfo/gluster-users" target="_blank">http://supercolony.gluster.org/mailman/listinfo/gluster-users</a><br></blockquote></div><br></div></div></div>