Nicolas, The latest TLA is undergoing some heavy modifications for replicate performance. Please avoid using the current repo codebase on a production system for another week or two. Avati On Tue, Feb 10, 2009 at 8:35 PM, nicolas prochazka <prochazka.nicolas@xxxxxxxxx> wrote: > hi, > with last tla, I've > > 009-02-10 15:56:31 D [afr-self-heal-data.c:983:afr_sh_data_lock] last: > locking /Calcul.01 on subvolume brick_10.98.98.2 > 2009-02-10 15:56:31 D [afr-self-heal-data.c:983:afr_sh_data_lock] last: > locking /Calcul.01 on subvolume brick_10.98.98.1 > 2009-02-10 15:56:31 D [afr-self-heal-data.c:935:afr_sh_data_lock_cbk] last: > inode of /Calcul.01 on child 1 locked > 2009-02-10 15:56:31 D [afr-self-heal-data.c:935:afr_sh_data_lock_cbk] last: > inode of /Calcul.01 on child 0 locked > 2009-02-10 15:56:31 D > [afr-self-heal-common.c:170:afr_sh_print_pending_matrix] last: > pending_matrix: [ -1 -1 ] > 2009-02-10 15:56:31 D > [afr-self-heal-common.c:170:afr_sh_print_pending_matrix] last: > pending_matrix: [ -1 -1 ] > 2009-02-10 15:56:31 E [afr-self-heal-data.c:812:afr_sh_data_fix] last: > Unable to resolve conflicting data of /Calcul.01. Pleas > e resolve manually by deleting the file /Calcul.01 from all but the > preferred subvolume. Please consider 'option favorite-chil > d <>' > 2009-02-10 15:56:31 D [afr-self-heal-data.c:252:afr_sh_data_finish] last: > finishing data selfheal of /Calcul.01 > 2009-02-10 15:56:31 D [afr-self-heal-data.c:228:afr_sh_data_unlock] last: > unlocking /Calcul.01 on subvolume brick_10.98.98.2 > 2009-02-10 15:56:31 D [afr-self-heal-data.c:228:afr_sh_data_unlock] last: > unlocking /Calcul.01 on subvolume brick_10.98.98.1 > 2009-02-10 15:56:31 D [afr-self-heal-data.c:185:afr_sh_data_unlck_cbk] last: > inode of /Calcul.01 on child 0 locked > 2009-02-10 15:56:31 D [afr-self-heal-data.c:185:afr_sh_data_unlck_cbk] last: > inode of /Calcul.01 on child 1 locked > 2009-02-10 15:56:31 D [afr-self-heal-data.c:70:afr_sh_data_done] last: self > heal of /Calcul.01 completed > 2009-02-10 15:56:31 D [fuse-bridge.c:368:fuse_entry_cbk] glusterfs-fuse: 34: > LOOKUP() /Calcul.01 => 178974282 (0) > 2009-02-10 15:56:31 D [inode.c:94:__dentry_hash] fuse/inode: dentry hashed > VM-PERSO001-XP_SYSPREP.MR (178974282) > 2009-02-10 15:56:31 D [inode.c:312:__inode_passivate] fuse/inode: > passivating inode(178974282) lru=2/0 active=3 purge=0 > 2009-02-10 15:56:31 D [inode.c:293:__inode_activate] fuse/inode: activating > inode(178974282), lru=1/0 active=4 purge=0 > 2009-02-10 15:56:31 D [fuse-bridge.c:1505:fuse_open] glusterfs-fuse: 35: > OPEN /Calcul.01 > 2009-02-10 15:56:31 W [afr.c:605:afr_open] last: returning EIO, file has to > be manually corrected in backend > 2009-02-10 15:56:31 E [fuse-bridge.c:662:fuse_fd_cbk] glusterfs-fuse: 35: > OPEN() /Calcul.01 => -1 (Input/output error) > 2009-02-10 15:56:31 D [inode.c:312:__inode_passivate] fuse/inode: > passivating inode(178974282) lru=2/0 active=3 purge=0 > > however file calcul.01 is equal on two backend ( same size and same hash md5 > ) > > Regards > Nicolas P. > > _______________________________________________ > Gluster-devel mailing list > Gluster-devel@xxxxxxxxxx > http://lists.nongnu.org/mailman/listinfo/gluster-devel > >
