[Gluster-users] Missing files with unify 2.0.0rc1

[Filipe Maia]

Digging a big more I found the following. When I do ls on the mounted
directory I get the following readdir on the server side:
2009-01-16 11:56:09 D [server-protocol.c:5000:server_readdir] ns:
READDIR 'fd=0; offset=0; size=4096
2009-01-16 11:56:16 D [server-protocol.c:5000:server_readdir] ns:
READDIR 'fd=0; offset=264; size=4096
2009-01-16 11:56:22 D [server-protocol.c:5000:server_readdir] ns:
READDIR 'fd=0; offset=527; size=4096
2009-01-16 11:56:35 D [server-protocol.c:5000:server_readdir] ns:
READDIR 'fd=0; offset=788; size=4096
2009-01-16 11:56:37 D [server-protocol.c:5000:server_readdir] ns:
READDIR 'fd=0; offset=1062; size=4096
2009-01-16 11:56:37 D [server-protocol.c:5000:server_readdir] ns:
READDIR 'fd=0; offset=1366; size=4096
2009-01-16 11:56:38 D [server-protocol.c:5000:server_readdir] ns:
READDIR 'fd=0; offset=2147483647; size=4096

That last readdir seems extremely suspicious. I guess for some strange
reason the client jumps to a very large offset.
I will see if find more on the client side.

On Fri, Jan 16, 2009 at 10:06, Anand Avati <avati at zresearch.com> wrote:
>> I *think* (and I'm sure Anand will correct me if I'm wrong), in the case of
>> a single brick, gluster doesn't care much about it's extended attributes,
>> but once another brick/node is involved (in unify or replicate), then the
>> extended attributes become important.
>>
>> pre-existing data is generally without Xattr's and so this causes confusion.
>> My guess is, adding the extended attributes (which happens when you copy the
>> file into the gluster mountpoint) would solve the problem.
>
> This is generally true, but in this situation he is using unify (which
> does not use xattrs on the backend) and most of the other cases, if
> the xattr is missing, the appropriate self heal will atleast try to
> set the most sensible xattr values when the file is first looked up.
>
> Avati
>