[Gluster-users] Recovering out of sync nodes from input/output error

Alex Florescu alex.florescu at tripsolutions.co.uk
Fri Apr 13 14:02:41 UTC 2012


On Fri, Apr 13, 2012 at 4:05 PM, Rodrigo Severo wrote:

> You are using *-d* and *-n* on the same getfattr. That's wrong AFAICT.
>
> Try *getfattr -d -m . -e hex -h BRICK/PATH/TO/FILE/OR/DIRECTORY
>
> *You should get a full list of extended attributes related to the
> file/directory.
>

Yes, now it's working. Thank you.
 So, for the previous scenario described already:
> Simulation follows:
> step 1
> node1:
> iptables -I INPUT 1 -s 10.0.2.15 -j DROP (connectivity loss simulation)
> touch /a/howareyou
>
> node2:
> touch /a/hello
>
> step 2
> node1:
> iptables -D INPUT 1 (connectivity recovery)
> ls /a
> ls: cannot access /a: Input/output error
>
> node2:
> ls /a
> ls: cannot access /a: Input/output error

node1:
getfattr -d -m . -e hex /local/
# file: local/
trusted.afr.vol-replication-client-0=0x000000000000000000000000
trusted.afr.vol-replication-client-1=0x000000000000000000000001

getfattr -d -m . -e hex /local/howareyou
# file: local/howareyou
trusted.afr.vol-replication-client-0=0x000000000000000000000000
trusted.afr.vol-replication-client-1=0x000000000000000100000000

node2:
getfattr -d -m . -e hex /local/
# file: local/
trusted.afr.vol-replication-client-0=0x000000000000000000000001
trusted.afr.vol-replication-client-1=0x000000000000000000000000

getfattr -d -m . -e hex /local/hello
# file: local/hello
trusted.afr.vol-replication-client-0=0x000000000000000100000000
trusted.afr.vol-replication-client-1=0x000000000000000000000000


On Fri, Apr 13, 2012 at 4:32 PM, Jeff Darcy wrote:
> Try changing "trusted.gluster.dht" to "trusted.glusterfs.dht" as had
> originally been suggested.  Alternatively, you could just use "-m ."
> instead of "-n trusted.gluster.dht" to dump *all* xattrs, and see what
> we get.

No .dht attribute, only afr as you can see.

> The reason you continue to get I/O errors is probably that the xattrs on
> the *parent directory* still indicate pending operations on both sides.

Indeed, this is as you said.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20120413/1a3ea94e/attachment.html>


More information about the Gluster-users mailing list