[Gluster-users] Strange behaviour in AFR - directory read only from first brick?

[Krishna Srinivas]

Baggio,

If the xattr versions are same on both the directories of AFR, then
it assumes that contents are also same, so when you wipe the
data on the first brick, you also need to make sure that when you
bring it back up, the version on the brick2 is more that version
on brick1. use "getfattr" to get version and createtime attrs
on the directories. the xattrs are trusted.glusterfs.version and
trusted.glusterfs.createtime.

Krishna

On Fri, Jul 4, 2008 at 11:10 AM, baggio liu <baggioss at gmail.com> wrote:
> Hi,
>    I have make some tests.
>
> 1. AFR is up (namespace and data brick between Server1 and Server2 have AFR)
> 2. touch file f1
> 3. Server1 crashes (remove data and namespace in Server1 )
>
> 4. ls on mount point, f1 exists and everything is normal (ls read from
> Server2)
> 5. gclusterfsd start on Server1
> 6. ls on mount point does not show f1 anymore (ls read only from brick1?)
> 7. cat f1 on client, and content of it can be seen, but ls can not work
> well.
>
> GlusterFS version 1.3.9 release
>
>
>
> Server1 spec vol:
>
> volume brick
>   type storage/posix
>   option directory /mnt/glusterfs/brick00
> end-volume
>
> volume ns
>   type storage/posix
>   option directory /mnt/glusterfs/ns
> end-volume
>
> volume server
>   type protocol/server
>   option transport-type tcp/server
>   option ib-verbs-work-request-send-size  131072
>   option ib-verbs-work-request-send-count 64
>   option ib-verbs-work-request-recv-size  131072
>   option ib-verbs-work-request-recv-count 64
>   option auth.ip.brick.allow *
>   option auth.ip.ns.allow *
>   subvolumes brick ns
> end-volume
>
> Server2 spec vol:
>
> volume remote-ns
>         type protocol/client
>         option transport-type tcp/client
>         option remote-host [server1 ip]
>         option remote-subvolume ns
> end-volume
>
> volume local-ns
>   type storage/posix
>   option directory /mnt/glusterfs/ns
> end-volume
>
> volume ns
>  type cluster/afr
>  subvolumes remote-ns local-ns
> end-volume
>
> volume remote-brick00
>   type protocol/client
>   option transport-type tcp/client
>   option remote-host 172.16.208.20
>   option remote-port 6996
>   option remote-subvolume brick
> end-volume
>
>
> volume local-brick00
>   type storage/posix
>   option directory /mnt/glusterfs/brick00
> end-volume
>
> volume brick00
>  type cluster/afr
>  subvolumes remote-brick00 local-brick00
> end-volume
>
> volume unify
>   type cluster/unify
>   option namespace ns
>   option scheduler rr
>   subvolumes brick00
> end-volume
>
> BTW, I'm not very clear about what arnulf said, but in my may, this problem
> can be seen.
>
>
> Baggio
>
>
> 2008/7/4 Krishna Srinivas <krishna at zresearch.com>:
>>
>> >>> 1. AFR is up
>> >>> 2. touch file f1
>> >>> 3. brick1 crashes
>> >>> 4. ls on mount point, f1 exists and everything is normal (ls read from
>> >>> brick2)
>> >>> 5. file system repair removes f1 from brick1
>>
>> Glusterfs removes f1 from brick1? Or do you manually remove it?
>> Could you also check with a later release. As a related bug was
>> fixed.
>>
>> Thanks
>>
>> >>> 6. gclusterfsd start on brick1
>> >>> 7. ls on mount point does not show f1 anymore (ls read only from
>> >>> brick1?)
>> >>> 8. cat f1 on mount point replicates file and it becomes visible
>>
>>
>>
>> On Fri, Jul 4, 2008 at 7:03 AM, baggio liu <baggioss at gmail.com> wrote:
>> > Hi,
>> >    A file can't "ls " ,but can "less ".
>> >    I think this action is a little weird. If this action can not be
>> > supp
>
>