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
