[Gluster-users] Problem: rsync files to glusterfs fail randomly~

Tue May 11 07:27:34 UTC 2010

    Thanks again, Joel! I'll give it a try~Hope it works for us too~

On Tue, May 11, 2010 at 3:24 PM, joel vennin <joel.vennin at gmail.com> wrote:

> In my configuration file, i've just remove the readahead translator
> definition. So you have to remove as you said the volume definition of
> read-ahead.
>
> Good luck !
>
>
> On Mon, May 10, 2010 at 4:28 PM, bonn deng <bonndeng at gmail.com> wrote:
>
>>
>>     Hi, Joel, thanks for your helpful reply! But how can I remove the
>> readahead translator? Simply remove the volume definition of read-ahead as
>> follows? Just to make sure of it, thanks~
>>
>> volume read-ahead
>>   type performance/read-ahead
>>   option force-atime-update  no
>>   option page-count   4
>>   subvolumes cache
>> end-volume
>>
>>  On Mon, May 10, 2010 at 9:58 PM, joel vennin <joel.vennin at gmail.com>wrote:
>>
>>> Hi,
>>>
>>> I got a similar problem, I found a work around to this issue by deactive
>>> the readahead translator. Once we removed the readahead translator
>>> everything worked fine. However, we have still an issue: using distribute a
>>> program is not able to open a file using the fopen function.
>>>
>>> Good luck
>>>
>>> On Mon, May 10, 2010 at 3:12 PM, bonn deng <bonndeng at gmail.com> wrote:
>>>
>>>>    Hello, everyone~
>>>>    We're using glusterfs as our data storage tool, after we upgraded gfs
>>>> version from 2.0.7 to 3.0.3, we encountered some wierd problems: we need
>>>> to
>>>> rsync some files to gfs cluster every five minutes, but randomly some
>>>> files
>>>> cannot be transfered correctly or evan cannot be transfered at all. I
>>>> ssh to
>>>> the computer where the rsync operation failed and check the log under
>>>> directory "/var/log/glusterfs", which reads:
>>>>
>>>> ……
>>>> [2010-05-10 20:32:05] W [fuse-bridge.c:1719:fuse_create_cbk]
>>>> glusterfs-fuse:
>>>> 4499440:
>>>> /uigs/sugg/.sugg_access_log.2010051012.10.11.89.102.nginx1.cMi7LW
>>>> => -1
>>>>  (No such file or directory)
>>>> [2010-05-10 20:32:13] W [fuse-bridge.c:1719:fuse_create_cbk]
>>>> glusterfs-fuse:
>>>> 4499542:
>>>> /sogou-logs/nginx-logs/proxy/.proxy_access_log.2010051019.10.11.89.102.
>>>> nginx1.MnUaIR => -1 (No such file or directory)
>>>>
>>>> [2010-05-10 20:35:12] W [fuse-bridge.c:491:fuse_entry_cbk]
>>>> glusterfs-fuse:
>>>> LOOKUP(/uigs/pblog/bdweb/201005/20100510) inode (ptr=0x2aaaac010fb0,
>>>> ino=183475774
>>>> 468, gen=5467705122580597717) found conflict (ptr=0x1d75640,
>>>> ino=183475774468, gen=5467705122580599136)
>>>> [2010-05-10 20:35:16] W [fuse-bridge.c:491:fuse_entry_cbk]
>>>> glusterfs-fuse:
>>>> LOOKUP(/uigs/pblog/suggweb/201005/20100510) inode (ptr=0x1d783b0,
>>>> ino=245151107323
>>>> , gen=5467705122580597722) found conflict (ptr=0x2aaaac0bc4b0,
>>>> ino=245151107323, gen=5467705122580598133)
>>>>
>>>> [2010-05-10 20:40:08] W [fuse-bridge.c:491:fuse_entry_cbk]
>>>> glusterfs-fuse:
>>>> LOOKUP(/uigs/pblog/bdweb/201005/20100510) inode (ptr=0x2aaab806cca0,
>>>> ino=183475774
>>>> 468, gen=5467705122580597838) found conflict (ptr=0x1d75640,
>>>> ino=183475774468, gen=5467705122580599136)
>>>> [2010-05-10 20:40:12] W [fuse-bridge.c:491:fuse_entry_cbk]
>>>> glusterfs-fuse:
>>>> LOOKUP(/uigs/pblog/suggweb/201005/20100510) inode (ptr=0x1d7c190,
>>>> ino=245151107323
>>>> , gen=5467705122580597843) found conflict (ptr=0x2aaaac0bc4b0,
>>>> ino=245151107323, gen=5467705122580598133)
>>>>
>>>> [2010-05-10 20:45:10] W [fuse-bridge.c:491:fuse_entry_cbk]
>>>> glusterfs-fuse:
>>>> LOOKUP(/uigs/pblog/bdweb/201005/20100510) inode (ptr=0x2aaab00a6a90,
>>>> ino=183475774
>>>> 468, gen=5467705122580597838) found conflict (ptr=0x1d75640,
>>>> ino=183475774468, gen=5467705122580599136)
>>>> [2010-05-10 20:45:14] W [fuse-bridge.c:491:fuse_entry_cbk]
>>>> glusterfs-fuse:
>>>> LOOKUP(/uigs/pblog/suggweb/201005/20100510) inode (ptr=0x2aaab80960e0,
>>>> ino=2451511
>>>> 07323, gen=5467705122580597669) found conflict (ptr=0x2aaaac0bc4b0,
>>>> ino=245151107323, gen=5467705122580598133)
>>>> ……
>>>>
>>>>    Does anybody know what's wrong with our gfs? And another question, in
>>>> order to trace the problem, we want to know to which machine the failed
>>>> file
>>>> should be put, where can I get this information or what can I do?
>>>>    By the way, we're now using glusterfs version 3.0.3, and we have
>>>> nearly
>>>> 200 data servers in the gfs cluster (in distribute mode, not replicate).
>>>> What else do I need to put here in order to make our problem clear if
>>>> it's
>>>> not now?
>>>>    Thanks for your help! Any suggestion would be appreciated~
>>>>
>>>> --
>>>> Quansong Deng(bonnndeng/邓泉松)
>>>>
>>>> Web and Software Technology R&D center
>>>> Dept. CST
>>>> Tsinghua University,
>>>> P.R China
>>>> 100084
>>>>
>>>> CELL: +86 135 524 20008
>>>>
>>>> _______________________________________________
>>>> Gluster-users mailing list
>>>> Gluster-users at gluster.org
>>>> http://gluster.org/cgi-bin/mailman/listinfo/gluster-users
>>>>
>>>>
>>>
>>
>>
>> --
>> Quansong Deng(bonnndeng/邓泉松)
>>
>> Web and Software Technology R&D center
>> Dept. CST
>> Tsinghua University,
>> P.R China
>> 100084
>>
>> CELL: +86 135 524 20008
>>
>
>

-- 
Quansong Deng(bonnndeng/邓泉松)

Web and Software Technology R&D center
Dept. CST
Tsinghua University,
P.R China
100084

CELL: +86 135 524 20008