Gluster users - Sep 2008 - Problem with some files not auto-healing still

Having fixed my problems with glusterfs crashing (which appears to be
related to symlinks in the cluster) I've found my problem with some files
not auto-healing has re-emerged. It's the same problem as before - gluster
is aware the files exist on the storage brick, but does not heal them to the
namespace.
 
Is there any way I can diagnose this problem? Could it be an issue with
gluster being unable to access the files (there are no permission
differences between these and others)? How does gluster detect discrepancies
between the namespace and bricks?
 
- Will
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://supercolony.gluster.org/pipermail/gluster-users/attachments/20080918/2fe59cce/attachment.html>

At 05:29 PM 9/17/2008, Will Rouesnel wrote:
>Having fixed my problems with glusterfs crashing (which appears to 
>be related to symlinks in the cluster) I've found my problem with 
>some files not auto-healing has re-emerged. It's the same problem as 
>before - gluster is aware the files exist on the storage brick, but 
>does not heal them to the namespace.
>
>Is there any way I can diagnose this problem? Could it be an issue 
>with gluster being unable to access the files (there are no 
>permission differences between these and others)? How does gluster 
>detect discrepancies between the namespace and bricks?
as I understand it, gluster uses 2 extended attributes.  One for some 
sort of timestamp and another for a version number (I think this is 
slightly changed in 1.4).

based on some criteria these are used to determine which machine has 
the latest version of the file.

what I remember seeing in the past was, if you have a filesystem 
which doesn't have extended attributes enabled, those files never got 
AFR'ed.  so I'm assuming this happens with any file whose extended 
attributes are missing.

I think gluster should, if a file doesn't have extended attributes 
one one machine and does on the other, the one without attributes 
should be overwritte with the other version and then given 
attributes.  but I think this may be so as to preserve files that 
aren't gluster manged, but I've no idea the thought process on that.

However, look at the extended attributes of the files not healing and 
I'll bet something wrong with them.


>
>- Will
>_______________________________________________
>Gluster-users mailing list
>Gluster-users at gluster.org
>http://zresearch.com/cgi-bin/mailman/listinfo/gluster-users

At 05:29 PM 9/17/2008, Will Rouesnel wrote:
>Having fixed my problems with glusterfs crashing (which appears to 
>be related to symlinks in the cluster) I''ve found my problem with 
>some files not auto-healing has re-emerged. It''s the same problem
as
>before - gluster is aware the files exist on the storage brick, but 
>does not heal them to the namespace.
>
>Is there any way I can diagnose this problem? Could it be an issue 
>with gluster being unable to access the files (there are no 
>permission differences between these and others)? How does gluster 
>detect discrepancies between the namespace and bricks?
as I understand it, gluster uses 2 extended attributes.  One for some 
sort of timestamp and another for a version number (I think this is 
slightly changed in 1.4).

based on some criteria these are used to determine which machine has 
the latest version of the file.

what I remember seeing in the past was, if you have a filesystem 
which doesn''t have extended attributes enabled, those files never got 
AFR''ed.  so I''m assuming this happens with any file whose
extended
attributes are missing.

I think gluster should, if a file doesn''t have extended attributes 
one one machine and does on the other, the one without attributes 
should be overwritte with the other version and then given 
attributes.  but I think this may be so as to preserve files that 
aren''t gluster manged, but I''ve no idea the thought process on
that.

However, look at the extended attributes of the files not healing and 
I''ll bet something wrong with them.


>
>- Will
>_______________________________________________
>Gluster-users mailing list
>Gluster-users at gluster.org
>http://zresearch.com/cgi-bin/mailman/listinfo/gluster-users

At 05:29 PM 9/17/2008, Will Rouesnel wrote:
>Having fixed my problems with glusterfs crashing (which appears to 
>be related to symlinks in the cluster) I''ve found my problem with 
>some files not auto-healing has re-emerged. It''s the same problem
as
>before - gluster is aware the files exist on the storage brick, but 
>does not heal them to the namespace.
>
>Is there any way I can diagnose this problem? Could it be an issue 
>with gluster being unable to access the files (there are no 
>permission differences between these and others)? How does gluster 
>detect discrepancies between the namespace and bricks?
as I understand it, gluster uses 2 extended attributes.  One for some 
sort of timestamp and another for a version number (I think this is 
slightly changed in 1.4).

based on some criteria these are used to determine which machine has 
the latest version of the file.

what I remember seeing in the past was, if you have a filesystem 
which doesn''t have extended attributes enabled, those files never got 
AFR''ed.  so I''m assuming this happens with any file whose
extended
attributes are missing.

I think gluster should, if a file doesn''t have extended attributes 
one one machine and does on the other, the one without attributes 
should be overwritte with the other version and then given 
attributes.  but I think this may be so as to preserve files that 
aren''t gluster manged, but I''ve no idea the thought process on
that.

However, look at the extended attributes of the files not healing and 
I''ll bet something wrong with them.


>
>- Will
>_______________________________________________
>Gluster-users mailing list
>Gluster-users at gluster.org
>http://zresearch.com/cgi-bin/mailman/listinfo/gluster-users

At 05:29 PM 9/17/2008, Will Rouesnel wrote:
>Having fixed my problems with glusterfs crashing (which appears to 
>be related to symlinks in the cluster) I''ve found my problem with 
>some files not auto-healing has re-emerged. It''s the same problem
as
>before - gluster is aware the files exist on the storage brick, but 
>does not heal them to the namespace.
>
>Is there any way I can diagnose this problem? Could it be an issue 
>with gluster being unable to access the files (there are no 
>permission differences between these and others)? How does gluster 
>detect discrepancies between the namespace and bricks?
as I understand it, gluster uses 2 extended attributes.  One for some 
sort of timestamp and another for a version number (I think this is 
slightly changed in 1.4).

based on some criteria these are used to determine which machine has 
the latest version of the file.

what I remember seeing in the past was, if you have a filesystem 
which doesn''t have extended attributes enabled, those files never got 
AFR''ed.  so I''m assuming this happens with any file whose
extended
attributes are missing.

I think gluster should, if a file doesn''t have extended attributes 
one one machine and does on the other, the one without attributes 
should be overwritte with the other version and then given 
attributes.  but I think this may be so as to preserve files that 
aren''t gluster manged, but I''ve no idea the thought process on
that.

However, look at the extended attributes of the files not healing and 
I''ll bet something wrong with them.


>
>- Will
>_______________________________________________
>Gluster-users mailing list
>Gluster-users at gluster.org
>http://zresearch.com/cgi-bin/mailman/listinfo/gluster-users

On Thu, Sep 18, 2008 at 3:35 AM, Keith Freedman <freedman at
freeformit.com>wrote:
> I think gluster should, if a file doesn't have extended attributes
> one one machine and does on the other, the one without attributes
> should be overwritte with the other version and then given
> attributes.  but I think this may be so as to preserve files that
> aren't gluster manged, but I've no idea the thought process on
that.
>
>From what I observe in 1.4pre5, if your filesystem doesn't support
extended
attributes, it'll fail to start.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://supercolony.gluster.org/pipermail/gluster-users/attachments/20080918/21fbacae/attachment.html>

At 12:28 PM 9/18/2008, KwangErn Liew wrote:
>On Thu, Sep 18, 2008 at 3:35 AM, Keith Freedman 
><<mailto:freedman at freeformit.com>freedman at freeformit.com>
wrote:
>I think gluster should, if a file doesn''t have extended attributes
>one one machine and does on the other, the one without attributes
>should be overwritte with the other version and then given
>attributes.  but I think this may be so as to preserve files that
>aren''t gluster manged, but I''ve no idea the thought
process on that.
>
>
> From what I observe in 1.4pre5, if your filesystem doesn''t support
> extended attributes, it''ll fail to start.
yes, but I''m thining about when it does support extended attributes 
and files end up in there that don''t have them.  (i.e. someone 
accidentally copied over a file using the underlying filesystem 
directly--gluster should recognize it and if there''s a version in the 
gluster world with attributes it takes precidence, otherwise, it adds 
the extended attributes and brings the file into the gluster world.

This would be handy and would make it much easier to start 
gluster--we wouldn''t have to do the weird manually adding xattrs or 
copying files into gluster.
What I''m trying to say is... if this were the case, I could take an 
existing 500GB filesystem, put gluster on it and immediately start 
using it.  this would be handy.  also I could take another one and 
add it to unify and gluster would add the xattrs as needed.

I suppose this could go on the wish list.

At 12:28 PM 9/18/2008, KwangErn Liew wrote:
>On Thu, Sep 18, 2008 at 3:35 AM, Keith Freedman 
><<mailto:freedman at freeformit.com>freedman at freeformit.com>
wrote:
>I think gluster should, if a file doesn''t have extended attributes
>one one machine and does on the other, the one without attributes
>should be overwritte with the other version and then given
>attributes.  but I think this may be so as to preserve files that
>aren''t gluster manged, but I''ve no idea the thought
process on that.
>
>
> From what I observe in 1.4pre5, if your filesystem doesn''t support
> extended attributes, it''ll fail to start.
yes, but I''m thining about when it does support extended attributes 
and files end up in there that don''t have them.  (i.e. someone 
accidentally copied over a file using the underlying filesystem 
directly--gluster should recognize it and if there''s a version in the 
gluster world with attributes it takes precidence, otherwise, it adds 
the extended attributes and brings the file into the gluster world.

This would be handy and would make it much easier to start 
gluster--we wouldn''t have to do the weird manually adding xattrs or 
copying files into gluster.
What I''m trying to say is... if this were the case, I could take an 
existing 500GB filesystem, put gluster on it and immediately start 
using it.  this would be handy.  also I could take another one and 
add it to unify and gluster would add the xattrs as needed.

I suppose this could go on the wish list.

At 12:28 PM 9/18/2008, KwangErn Liew wrote:
>On Thu, Sep 18, 2008 at 3:35 AM, Keith Freedman 
><<mailto:freedman at freeformit.com>freedman at freeformit.com>
wrote:
>I think gluster should, if a file doesn''t have extended attributes
>one one machine and does on the other, the one without attributes
>should be overwritte with the other version and then given
>attributes.  but I think this may be so as to preserve files that
>aren''t gluster manged, but I''ve no idea the thought
process on that.
>
>
> From what I observe in 1.4pre5, if your filesystem doesn''t support
> extended attributes, it''ll fail to start.
yes, but I''m thining about when it does support extended attributes 
and files end up in there that don''t have them.  (i.e. someone 
accidentally copied over a file using the underlying filesystem 
directly--gluster should recognize it and if there''s a version in the 
gluster world with attributes it takes precidence, otherwise, it adds 
the extended attributes and brings the file into the gluster world.

This would be handy and would make it much easier to start 
gluster--we wouldn''t have to do the weird manually adding xattrs or 
copying files into gluster.
What I''m trying to say is... if this were the case, I could take an 
existing 500GB filesystem, put gluster on it and immediately start 
using it.  this would be handy.  also I could take another one and 
add it to unify and gluster would add the xattrs as needed.

I suppose this could go on the wish list.

On Thu, Sep 18, 2008 at 11:54 PM, Keith Freedman <freedman at
freeformit.com>wrote:
> At 12:28 PM 9/18/2008, KwangErn Liew wrote:
> >On Thu, Sep 18, 2008 at 3:35 AM, Keith Freedman
> ><<mailto:freedman at freeformit.com>freedman at
freeformit.com> wrote:
> >I think gluster should, if a file doesn't have extended attributes
> >one one machine and does on the other, the one without attributes
> >should be overwritte with the other version and then given
> >attributes.  but I think this may be so as to preserve files that
> >aren't gluster manged, but I've no idea the thought process on
that.
> >
> >
> > From what I observe in 1.4pre5, if your filesystem doesn't support
> > extended attributes, it'll fail to start.
>
> yes, but I'm thining about when it does support extended attributes
> and files end up in there that don't have them.  (i.e. someone
> accidentally copied over a file using the underlying filesystem
> directly--gluster should recognize it and if there's a version in the
> gluster world with attributes it takes precidence, otherwise, it adds
> the extended attributes and brings the file into the gluster world.
>
Ah I see, AFAIK, GlusterFS does this automatically even in 1.3.x or are you
experiencing the opposite?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://supercolony.gluster.org/pipermail/gluster-users/attachments/20080919/86370eb4/attachment.html>

I think I need to clarify my original mail - I'm not running an AFR'd
setup
- my problem is I have files not showing up under the unify translater
despite existing on one of the storage bricks it encompasses.

- Will