You should try upgrading to the 2.0.0 release and try again. They fixed all sorts of bugs. liam On Thu, May 7, 2009 at 8:21 AM, Sacerdoti, Federico < Federico.Sacerdoti at deshawresearch.com> wrote: > Hello, > > I am evaluating glusterfs and have seen some strange behavior with > remove. I have gluster/2.0.0rc4 setup on 10 linux nodes connected with > GigE. The config is Nufa/fuse with one storage brick per server, as seen > in the attached nufa.vol config file, which I use for both clients and > servers. > > My experiment is to launch 10 parallel writers, each of whom writes > 32GiB worth of data in small files (2MB) to a shared gluster-fuse > mounted filesystem. The files are named uniquely per client, so each > file is only written once. This worked well, and I am seeing performance > close to that of native disk, even with 8-writers per node. > > However when I do a parallel "rm -rf writedir/" on the 10 nodes, where > writedir is the directory written in by the parallel writers described > above, I see strange effects. There are 69,000 UNLINK errors in the > glusterfsd.log of one server, in the form shown below. This alone is not > surprising as the operation is ocurring in parallel. However the remove > took much longer than expected, 92min, and more surprisingly the rm > command exited 0 but files remained in the writedir! > > I ran rm -rf writedir from a single client, and it too exited 0 but left > the writedir non-empty. Is this expected? > > Thanks, > Federico > > --From glusterfsd.log-- > 2009-05-04 11:35:15 E [fuse-bridge.c:964:fuse_unlink_cbk] > glusterfs-fuse: 5764889: UNLINK() /write.2MB.runid1.p1/5 => -1 (No such > file or directory) > 2009-05-04 11:35:15 E [dht-common.c:1294:dht_err_cbk] nufa: subvolume > drdan0192 returned -1 (No such file or directory) > 2009-05-04 11:35:15 E [fuse-bridge.c:964:fuse_unlink_cbk] > glusterfs-fuse: 5764894: UNLINK() /write.2MB.runid1.p1/51 => -1 (No such > file or directory) > --end-- > <<nufa.vol>> > > _______________________________________________ > Gluster-users mailing list > Gluster-users at gluster.org > http://zresearch.com/cgi-bin/mailman/listinfo/gluster-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://zresearch.com/pipermail/gluster-users/attachments/20090507/270e8274/attachment.htm>
